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ABSTRACT 


This thesis will focus on field testing and evaluating 





the capabilities of a smartphone-based system and associated 
equipment for “First Responder Networking.” Further, we 


will identify information sharing requirements for 





supporting a medical triage tasking during mass casualty and 








humanitarian operations. Thes requirements will be 





implemented, tested and evaluated against the capabilities 





of the TwiddleNet system for passing/sharing of patient 
information and records, in the form of text, photos and 


voice, rapidly disseminated to those involved with the 





Mobile Emergency Command Post unit and the Joint Operations 
Command Center. This will facilitate communication via 
synchronized backhaul or satellite communiqué from the 


disaster site to other medical facilities across a globally 





distributed network. For example, land based military 
medical units, naval hospital ships, stateside medical 


centers via tele-medicine, etc. The applicability of these 








efforts to the DoD will be specifically tested via 
integrated mass casualty/triage scenarios and simulated 


humanitarian operations. 
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I. INTRODUCTION 


Today’s smartphones are just as powerful as regular 
personal computers (PCs) were a few years ago. Their 
advanced capabilities can support a number of smartphone- 
based systems. These powerful devices can be converted to 


personal servers to be used for instantaneous data capture 





and dissemination in support of “First Responder Information 














Sharing.” This thesis tests and evaluates the capabilities 
of a smartphone-based system and associated equipment for 


“First Responder Networking.” TwiddleNet, a wireless system 





implemented using handheld-based infrastructure, is the 





First Responder application used as the platform for 


instantaneous data capture and dissemination. 


A. DEFINITION OF TWIDDLE 





Definition: (Verb) - To twist, move, or fiddle with 





something, typically in a purposeful or nervous way. 


deg Twiddle one’s thumbs - rotate one’s thumbs around 


each other with the fingers linked together. 








2. Be bored or idle because one has nothing to do 


Today’s cell phones are constantly twiddling.. awaiting 


calls or data to be passed! 


B. TWIDDLENET APPLICATIONS 


1. Advanced Handheld Communications Hardware 


Use of advanced handheld communications hardware via 


smartphones to facilitate: 





a. Instantaneous capture of data in support of 
medical triage that can be tagged and disseminated using any 


accessible mobile WiFi network. 


b. Mobile Emergency Command Post team members and 


First Responder groups maintain complete autonomy of all 





captured data, which is shared among specified team members, 
stored for redundancy by the Mobile Emergency Command Post 


server and later discriminately disseminated or shared. 








Cc. System parameters that allow exploitation of 





multiple communications that are limited only by the 
physical limits of the communications, which in turn are 


limited only by the physical limits of the hardware 


2. Gateway 


A gateway is established involving mobile personal 
servers that run on networked handheld devices or 
smartphones where the server content is completely 


autonomous. The privacy of personal information remains 





intact due to the contained WiFi network cloud that is 





created by the TwiddleNet access point, or the private local 
WiFi cloud maintained by the Network Operations Center (NOC) 


of the onsite Command and Control Center. 


Cc. PRIMARY OBJECTIVES 





Our primary objectives will be to determin th 
functional performance of the TwiddleNet system and document 


softwar developments as it relates to First Responder 





capabilities and medical triage. This work will identify 


on identifying sharing requirements for supporting scalable 


medical triage tasking teams during mass casualty and 





humanitarian operations and perform a system-level test and 





evaluation of the TwiddleNet system. 


D. SMARTPHONE CAPABILITIES OF CONTENT CAPTURE 


The smartphone capabilities for data content capture 











include: 
e Immediate content capture and dissemination. 
e Full autonomy of content and data. 
e Instantaneous data tagging. 
° Selected group sharing. 
E. PRIVACY REQUIREMENTS FOR FIRST RESPONDERS 
1. General Specifications 


There must be a separation of information from 
different domains and groups using the same system in the 


local TwiddleNet network or local adhoc network. This will 





allow access to content and data by First Responder team 


members, which is otherwise inaccessible to individuals 





outside of the First Responder teams; and a Push/Pull 
coordination for all data, to facilitate data being “Pushed” 


to specified recipients and data that can be accessed and 





downloaded by any recipient or team member. 


2. Specific Requirements 


a. Local adhoc networks or access to the TwiddleNet 





Mobile network, with a dedicated block of IP addresses to 


accommodate all TwiddleNet components. This will provide 





closed communication with the local network administrator 


and provide a standard of understanding by all users within 








the local network, not to interfere with dedicated IP 


addresses for the TwiddleNet system. 








be Many privacy threats related to mobile networks 
are a constant issue within the Information Operations 
Domain. The Military must protect communications related to 


force protection to mitigate threats to content privacy. 
Safeguarding all personal information, with respect to 


medical triage operations, is a criticality. 


on Our testing will assume that eavesdropping and 
surveillance are not being conducted. Our testing is 
focused on the functional requirements rather than the 


security of the network. 


F. OBJECTIVES 


1. Test and Evaluate Deployment 


Our objective is to test and evaluate the TwiddleNet 
System and the setup of the TwiddleNet Mobile Emergency 


Command Post for First Responder teams in support of 


Humanitarian Assistance missions and Medical Triage 
operations. 

2: Research Question 

a. “How can the DoD deploy a Mobile Emergency Command 


Post for ‘First Responder Capability’ when there is no 


available network infrastructure?” 





3°. Secondary Research Questions 


a. “How can victims be medically triaged and 
information stored and disseminated across a globally shared 


network?” 


1 “What is the current and future state of the DoD’s 
on-site disaster ‘First Responder Capabilities’ and Mobile 


Emergency Command Posts?” 


G. SCOPE 





Interest is focused on test and evaluation of the 


following: 





1. Information capture and sharing within groups of 








authorized users. 


Zs TwiddleNet group streaming capabilities. 





3 Group sharing options within the local adhoc 


network or the TwiddleNet Mobile Network. 





4. Utilization of TwiddleNet Fly Away Kit (FLAK) for 


deployment of rapid response teams. 


5 Utilization of the “TwiddleNet Gateway” abilities 
to communicate with specified receivers (e.g., NPS 


TwiddleNet Network Lab). 





O-. Incorporation of satellite communications via a 
Broadband Global Area Network (B-GAN) to create a stable 
backbone for reach-back options to other distant or global 


medical facilities. 





HP iPAQ smartphones with mobile network system 


capabilities will be used as a platform for the TwiddleNet 





5 


system implementation. The scope is limited to changes to 
the TwiddleNet software and architecture and the equipment 


capabilities. 


The research is limited to the application layer of the 








OSI Reference Model as changes to the operating system and 
network stack are beyond the availability and visibility of 


the researcher. 





Testing will be conducted during specified field 





scenarios equivalent to natural disasters such as Hurricane 





Katrina, the Boxing Day Tsunami of 2004, and other types of 


mass casualty circumstances. 

H. ORGANI ZATION/METHODOLOGY 
Research will be conducted in the following phases: 
1. Phase 1: Development of Metrics and Test Plan 


This phase will include the necessary academic review 





of existing technical material and hardware for the 
TwiddleNet network. Measure of Performance and Measure of 


Effectiveness (MOP/MOE) will be created. These MOPs/MOEs 





will be used to develop an ffective test and evaluation 


plan. 


2. Phase 2: Base-Lining and Experimentation 


This will be an overview of the utilization of testing 


and evaluation plan used with the TwiddleNet system when 





integrated with various streams of the network data. The 
TwiddleNet System will be connected to the Naval 


Postgraduate School (NPS) Cooperative Operations and Applied 


Science and Technology Studies (COASTS) adhoc network during 


















































the following Field Experiments (FEX): 
a. 2008 COASTS Camp Roberts FEX 
b. 2008 COASTS Thailand FEX IV/V. 
ons 2009 COASTS Camp Roberts FEX / 
During thes xercises, determination of usefulness and 














operating procedures for future use within a DoD supported 
network will be explored. The TwiddleNet system will be 
connected ES multiple networks in other operating 
environments through satellite communication utilizing a B- 


GAN while the TwiddleNet team is deployed to remote areas, 








such as Thailand, to further th perspectives of system 





ffectiveness. The TwiddleNet team will utilize the Gateway 





Application (introduced in the 4‘? Iteration) for reach-back 





to global or remote C2 sites (e.g., NPS TwiddleNet Lab, 
Joint Operations Command and Control (JOCC) /Tactical 


Operations Center (TOC) ) 


3: Phase 3: Analysis of Results and Conclusions 


The final phase will consist of analyzing the results 
of each case study and each simulated natural disaster 


scenario. The results will be compared to the baselined 





system and compared to the MOP/MOEs determined in Phase 1. 


By comparing the results from the case studies to the 











baseline and MOP/MOE’s, it will be possible to determine th 





ffectiveness and feasibility of deploying the system in 








real-world DoD environments. 


I. CHAPTER OUTLINE DESCRIPTION 





Chapter I gave a brief introduction to the TwiddleNet 
System. This encompassed the primary objectives of this 


work, the proposed applications, general and specific system 








requirements, and the scope and methodology utilized for the 


evaluation of the TwiddleNet System. 











Chapter will provide an extensive background narration 








of the first three TwiddleNet iterations. This chapter will 
also include a breakdown of the TwiddleNet Architecture and 


the pros, cons, design and operational issues for the first 





three TwiddleNet iterations. 

















Chapter will provide the specific metrics used for 


determination of feasibility of TwiddleNet iterations 1-3. 





An overview of applicable areas of use will be provided, 
along with a thorough description of each TwiddleNet 


Hardware Component. 








Chapter IV will provide an xtensiv description of 
Fourth Generation TwiddleNet, to include pros, cons and 


design flaws. 


Chapter V will describe the testing methods used. This 
will include a breakdown of the Measures of Performance 


(MOPS) and Measures of Effectiveness (MOEs). 





Chapter VI will explain the different scenarios and 
testing venues that incorporated all four iterations of 
TwiddleNet, to include test data and results of the first 


three iterations. 











Chapter V will provide summary and conclusions; 





discussing how TwiddleNet can be incorporated into DoD 


applications and future work for the TwiddleNet System. 
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II. BACKGROUND 


This section provides a general overview of the 
TwiddleNet system as applicable to a medical triage 


application. Additional preamble will include specifics of 











the TwiddleNet architecture and historical details of the 


TwiddleNet iterations throughout its 2.5-year evolution. 


A. TWIDDLENET OVERVIEW 


Today’s smartphones are no longer just phones; they are 


no longer used for just vocal communications. They are just 





as powerful as regular personal computers (PCS) were a few 
years ago. They contain at least 600 MHz processors, going 
as high as 1 GHz (in the very near future). For the new 
models of smartphones, their memory is often 256 Mbytes with 


an unlimited amount of storage capacity. 


But there are at least two important reasons that 


illustrate why these little handheld devices are profoundly 





better than a PC for certain applications: 


1. Content Capture Capability - These handheld 
devices come pre-equipped with the capability to capture 


images, video, sound, and text. 





25 Networking Capability There are at least four 
types of networking capability built into today’s 





smartphones: Global System for Mobile communication (GSM), 
2.5 or 3.0 Gig high-speed networking, Wireless Fidelity 
(WiFi) and Bluetooth. All of these networking modalities 


are readily available on this little handheld device. 





This power can basically enable instantaneous and real- 
time content capture and dissemination among first 
responders or military units through the powerful means of 


TwiddleNet. 


TwiddleNet exploits a smartphone-based networking 





system to harness the untapped resources to create an 





autonomous network of personal mobile servers. Its 
usefulness in scalability allows for adjustment to any 


operational size, either planned or “on the fly” emphasizing 





the high level of success for any mission. 


1. Medical Triage and Information Sharing 


Throughout history, natural, accidental and willful 
disasters have had profound effects on a global scale. Ona 
macro level, the persistent challenges met by first 
responders at each major disaster site are a lack of a 


communications system, a preponderanc of fractured 








structures, a lack of situational awareness, fractured 
command and control organization and retarded deployment of 
resources. Tragedies such as Hurricane Katrina in 2005, the 
September 11 attacks of 2001, the Oklahoma City bombing in 


1995 and Hurricane Andrew in 1992, medical triaging 





involving first responders, firefighters, police and 


military elements, have gleaned from lessons learned due to 





communication failures. A reliable communication and 


networking system is critical within the first 24-48 hours 





of responding to a disaster. 





In the realm of crisis and disaster response, the 





advent of “Hastily Formed Networks,” (Denning, 2006) has 


emerged as a strong solution to support the communication 
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challenge of any major disaster. And within this realm, 





TwiddleNet has secured a position as a viable and worthwhile 
initiative. The TwiddleNet system was created and 
inaugurated in 2005 by two Naval Postgraduate Students (NPS) 


enrolled in the Computer Science department, Capt. Jonathan 





Towle, USMC, and LT Christopher Clotfelter, USN [1]. The 








students recognized the immense communication power within 





today’s mobile devices, offering a variable range of content 
capturing capabilities, to include acceptably high 


resolution pictures, videos and sound/voice recordings. 





They also recognized the significant evolutionary processing 
power of current mobile devices, surpassing that of legacy 


PCs of less than four years ago. And finally, they 








recognized that a strong need Xisted to streamline the 


communication process for deployed first responder units; to 





eliminate the requirements to bring large, bulky components 





on site or into the field to capture, upload and disseminate 





important data among the field team members and to the 





Command and Control center. 


B. TWIDDLENET ARCHITECTURE 


1. TwiddleNet System 


The TwiddleNet system was designed to allow users to 
utilize smartphones as personal servers; to capture or 


gather information and data and share instantaneously within 





a protected WiFi cloud. The premise is based on a 


“Push/Pull” technology, designed to allow users to “push” 





information to active recipients and team members or for 
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these same team members to “pull” information from the 
system database for instantaneous download onto their 


personal handheld device. 


This model of content sharing is fundamentally 
different from content sharing in other portals such as 


Flickr ! and You Tube ? because after the data is captured, 











it must then be uploaded onto the portal using a PC to allow 














others to see it. The consequences that accompany this mode 
are: 

a. This takes time 

b. This is harder to use 

@. The content is under someone else’s control 

d. Data is exposed to the public Internet 





But with the TwiddleNet approach, the content is 
captured, automatically tagged, alerts are sent out to all 


team members, and whoever receives an alert can retrieve th 








data with their own handheld devices. And this, “Smart 
Push/Pull” data processing is a catalyst in the quest for 


information superiority and Network-—Centric Warfare [16]. 


2. TwiddleNet Programming 


The TwiddleNet system was designed to run on a 


Microsoft Windows® Mobile Operating System. This software 





application exploits the mobile network by utilizing a 


1 Flickr - Online photo management and sharing tool. 


2 You Tube - Allows people to easily upload and share video clips 
across the Internet through Web sites, mobile devices, blogs, and email. 
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“push/pull” technology? of data distribution. The user will 











gather all data and information and while maintaining full 




















control, will distribute to all eligible recipients. Users 
can control or specify the eligibility of recipients 
directly on their personal handheld device. 


The metadata sent is specifically characterized at 


creation, which significantly reduces network load and 





increases network capacity and speed. Each recipient is 
given an alert upon receipt of the metadata, both auditory 


and visual. Recipients can then choose to download the data 





file instantaneously on their personal handheld device, or 


at a more convenient time. 


The TwiddleNet system is comprised of ten components 





[2], as depicted in Figure 1. 





3 Push: A data distribution technology in which selected data are 
automatically delivered into the user's computer at prescribed intervals 
or based on some event that occurs. Pull: The user specifically asks for 
something by performing a search or requesting an existing report, video 
or other data type. Browsing the Web is an example of the pull model. 
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Figure 1. TwiddleNet Components 


a. Content Creation 





In the cyber realm, content can be depicted as any 





form of communication by the smartphone, i.e., text, photo, 
video, or attached file. The content is created by the 
user, tagged accordingly and then manually or automatically 


shared. 


b. Tagging 


Tagging of the content is automatic, consisting of 
the user/creator name, date and timestamp, file name, file 


size, and location (if GPS activated). Tagging of the data 





created acts as a record that is stored within the device’s 
memory, as well as the database as Extensible Markup 


Language (XML) documents, so that distribution within the 





network can simultaneously occur. 
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(ape Network 


The TwiddleNet system uses WiFi or GSM, which are 














both Internet Protocol (IP) driven. Fach piece of system 











hardware must have its own dedicated Internet routable IP 





address to properly send and receive all metadata within the 





WiFi cloud. 


The WiFi cloud can be a local network, generated 








by the Network Operation Center (NOC), subcomponent of the 


Joint Operation Command and Control (JOCC) center, where a 





specific block of IP addresses are dedicated to the system. 





Or, the deployed TwiddleNet system can generate a private 





WiFi cloud in which to operat securely and autonomously. 


This “mobile” WiFi cloud will be thoroughly explained later 








in Chapter IV. 


d. Database 





The system infrastructure utilizes a relational 


database. The database stores all metadata and their tags. 





The smart caching is executed utilizing database tables. 


e. Smart Cache 


As users create their data, multiple copies of the 





original data is “smart cached” or stored within the 


database utilizing proxy servers for future retrieval. This 





eliminates an overload within the network by sharing the 
workload over several servers thereby reducing the traffic 
within the network so that cached copies can be utilized to 


service multiple user retrieval requests. 
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Fe User Accounts 


Fach handheld device requires the user to log in 














with specific user name identifications (ID), which consist 
of the team member name and number, and it is then 
incorporated into the content tag. This allows the system 








translation scheme to seamlessly track all IP addresses and 








username ID for metadata storage, dissemination and 


retrieval. 


g. Metadata Dissemination 


The TwiddleNet system utilizes a single main 





network distribution device called the Portal. The Portal, 

















which will be explained in depth in Chapter , veceives 





all metadata from all users and instantaneously disseminates 








the data to all specified recipients operating within the 





WiFi cloud. The actual content sharing is done by Hypertext 
Transfer Protocol (HTTP) to ensure compatibility between Web 


browsers [2]. 


h. Online Search 


When a user or team member must search for a 


specific data file at a later time, it can be accessed via 





the portal through a Web browser based application. This 





allows online searching for data retrieval. Additionally, 
user can also retrieve files from the Portal via the 


handheld device or “Client” application that operates 








directly on the smartphone. Both alternatives allow the 


user to do a query text search for categories specifying 
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“Keyword,” “Group,” or “Author.” The result of each query 
must be “pulled” and downloaded by the user in order to view 


its content. 


Ti, Security Protocol 





In present day society, security of private 
information remains the utmost importance regardless of the 


situation. When deployed for Humanitarian Assistance 














Disaster Response (HADR), TwiddleNet team members will have 





purview of personal details that must be safeguarded within 





the TwiddleNet system. To accomplish this, the TwiddleNet 


application utilizes the security features of the 











smartphone. This includes incorporating a Wired Equivalent 





Privacy (WEP) and WiFi Protected Access with Pre-Shared Key 


(WPA-PSK) using the Temporal Key Integrity Protocol (TKIP) 








for data encryption. Additionally, for the GSM domain, the 





security of General Packet Radio Service (GPRS) is exploited 


for data transfer protocol. At this time, the current 





TwiddleNet application does not have the individual ability 











for confidentiality, integrity or authentication protocols. 


j. TwiddleNet Toolbox 


The TwiddleNet Toolbox consists of the specialized 


system component called the “Command Post,” which will be 

















explained in detail in Chapter 


Cc. FIRST ITERATION 


As mentioned earlier, the genesis of TwiddleNet was 
accomplished by two NPS students, Christopher T. Clotfelter 
and Jonathon E. Towle [1]. As a premise to the TwiddleNet 
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inception, they found that each deployed unit, 1.¢€., 
medical, military, law enforcement or firefighters, had to 
transport several different types of photographic apparatus, 
communication equipment, electronic components, multiple 
power sources and other miscellaneous bulky items in order 
to obtain a rapid and detailed picture for complete 
situation awareness. This recognition spawned the notion 


that there was a significant need to streamline the process 








of gathering and disseminating real-time information out in 











the “field”; i.e., Battlefield, Disaster Field, etc. 





Additionally, in those areas affected by natural and/or 





manmade disaster, it is more common than not to lack basic 


essentials crucial to a viable communication network. 





Necessities, such as shelter, power, and WiFi capabilities 





are absent, specially in areas of natural disaster. The 
need for Hastily Formed Networks (HFN) [3] was clearly 


evidenced by such impetus from recent historical events like 








9-11, Hurricane Katrina and the Indian Ocean earthquake 


causing the 2004 Asian Tsunami. The severity of these 





events, and many others like them, had proven the importance 
of a strong, reliable and quality network system to aide in 


humanitarian assistance and disaster relief fforts. The 





need for the ability to create a usable “on-the-fly” network 


to gather and share information was the catalyst for 





TwiddleNet. 





By harnessing the mobile intelligence and power of 


smartphones, the first iteration of TwiddleNet was created 
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in 2007, with Clodfelter and Towle’s research focusing on 





the “Metadata Tagging and Data Dissemination in Mobile 








Device Networks.” [1]. 


According to [1], Clodfelter and Towle exploited the 
supremacy of these handheld devices to instantly capture and 


disseminate data while commanding full control of all 








content, making it accessible to anyone with prior approval. 


Through a combination of automatically generated 
and user input metadata tag values, TwiddleNet 
users can locate files across participating 
devices. Metaphor appropriate custom tags can be 
added as needed to insure efficient, rich and 
successful fil searches. Intelligent data 
dissemination algorithms provide context 
sensitive governance to the file transfer scheme. 
Smart dissemination reconciles device and 
operational states with the amount of requested 
data and content to send, enabling providers to 
meet their most pressing needs, whether that is 
continuing to generate content or servicing 
reguest [1]. 


























The key development architectural scheme of TwiddleNet 
First Generation was a type of file sharing model or Server- 
Client model; this produced a successful peer-to-peer file- 
sharing network.4 Within this centralized sharing network, 
the Portal tracks all data files and images in the database, 
acting as a centralized gateway to all systemic nodes, 


recipients and data warehouses for the shared information. 





4 Peer-to-Peer Network: A peer-to-peer computer network architecture 
is an architecture in which each node has the same capabilities and 
either node can initiate a communication session. This technology is 
typically used for connecting nodes via largely ad hoc connections. 


21 





Ls Pros 


Successful testing of First Generation TwiddleNet 
comprised of capturing and disseminating data to all users 
and recipients in the controlled environment of the NPS 
TwiddleNet TwiddleNet Lab. All TwiddleNet hardware 
components associated to the local NPS WiFi lab and to each 
other, creating a strong social network. Generated photos 
were clear, tagging of each photo was accomplished, and 


dissemination of the data in real-time was successful. 


2. Cons 


Although brilliant in concept, the First Generation 
TwiddleNet had fundamental issues that caused instability in 
network connectivity among primary TwiddleNet hardware 
components like the Portal and Handheld Clients (For 


thorough description of TwiddleNet hardware components, see 














Chapter 2) This continuing issue had cascading 





repercussions, causing handheld clients to be frequently 


dropped or disconnected from the network, leading to 











captured content never reaching intended recipients. 





Additionally, the range and battery life of the basic 
components were less than desirable. The handheld clients 


could not travel very far from the portal due to the 











instability of the network signal. The battery life of the 


handheld clients were less than optimal, lasting at best 20 








minutes, which I could only surmise was due to the 








inefficiencies/redundancies of the program, coupled with the 
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large size of data being captured causing reduction in 


bandwidth which also drained battery life at an exponential 





rate. 


D. SECOND ITERATION 


The Second Generation TwiddleNet (2008) expanded the 





First Generation by another NPS student, Antonios Rimikis, 


directing his research on creating, “A Lightweight 





TwiddleNet Portal,” [4]. This thesis involved leveraging 


the capabilities of, 





.mobile personal members, mobile social networks 
and media sharing models and developing a 
TwiddleNet portal running on a smartphone or PDA 
so that the entire TwiddleNet system can be run 
on handheld devices for rapid deployment in 
emergencies [4]. 








dy Pros 


The ability for a single TwiddleNet Handheld Device or 








Client to function as the “Portal” allows for complete 





mobility and autonomy of the deployed system. 


2% Cons 





Ther wer several concerning issues with this 





iteration that occurred during lab and off site deployment 
of the system. These issues are listed under Operational 


and Design categories. 
a. Operational 


(1) After every attempt to download an image, the 





system would freeze, calling for a constant reset of the 


23 





handheld device and re-association into the system. This 
was a serious degradation of the quick and real-time 


dissemination of captured data. 


(2) The specific TwiddleNet Client with the dual 





activity of “Portal” could not continue to “gateway” any 
other information from other handheld devices until the 
error from the malfunctioning client had been corrected. 


This was also a major factor in degradation of the system. 


(3) There was no reliable “multithreading” 





application available. Team members were required to wait 
for the completion of each sharing cycle prior to beginning 


a new one. 


(4) Team members had to stay within close 
proximity of the handheld device with the dual 
responsibility of “Portal” to maintain connectivity to 








ensure data reached the portal for proper dissemination. 





Built-in antennas within the smartphones limited perimeter 











distance that the team members could loiter away from the 





Portal. 


(5) The TwiddleNet-Client/Portal would drain 





battery much faster and therefore had to be continually 





charged or kept close to a power source, which also hampered 





perimeter distance of team members. 


b. Design 


(1) After unexpected disconnection from the 
system or interrupted connectivity from the portal, the team 


member’s collected data would not be collected and therefore 








storage to the database could not occur. 
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(2) There was a very noticeable time delay for 


the TwiddleNet Client/Portal database to receive any shared 





data. It was confirmed [by Rimikis] that the best solution 


to eliminate this error was to employ a dedicated server to 





continually run in the background. 


E. THIRD ITERATION 





The Third Generation TwiddleNet was created by Dirk 
Ableiter (2008), directing his study on the smart caching 


portion of the TwiddleNet program, specifically “Smart 





Caching for Efficient Information Sharing in Distributed 











Information Systems,” [2]. His thesis specifically detailed 


solutions to the combined issues of, 


.Consumers’ demands to share information showing 
the need for utilizing the mobile devices more 
efficiently... This thesis offers an algorithm 
that will conserve battery power and bandwidth, 
depending on demand and device capabilities... the 
algorithm will select the content that will most 
efficiently reliev thes two resources and 
temporarily upload it to a proxy server that will 
serve the content on its behalf. This ‘smart’ 
temporary, caching will last as long as the 
bandwidth or battery level limits are exceeded 
alte 















































1. Pros 


a. Operational 


(1) Photos and data were successfully captured 





and disseminated to all recipients logged onto the 
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TwiddleNet network. All data was successfully tagged by the 
creator and each recipient was able to download data at 


their discretion or leisure. 


b. Design 


(1) The TwiddleNet software application continues 





to support the advanced, real-time secure file sharing; each 
smartphone able to act as content creator and retaining the 


ability to directly serve user requests in a peer-to-peer 





fashion. TwiddleNet continues to function in a streamlined 





manner, allowing the user to capture and disseminate 


specific characterizing metadata, thereby reducing network 





load considerably. In other words, if the recipient 








actually desired to view the file, the file could then be 





downloaded directly onto his or her own personal handheld 








device without threat of system overload and possible 


suspension of application during file download. 


(2) Conservation of battery power and bandwidth 
were successfully achieved, by creating an algorithm that 


efficiently selected sets of data that represented the 





actual content and temporarily storing them on ae proxy 
server. The proxy server, serving the content on behalf of 


the creator, would invoke a "smart caching," [2] to store 





the data on the portal until recipients were ready for 





receipt by other team members. This smart caching would take 





over when the battery life of the TwiddleNet Client when the 








battery level reached 34%, 50%, or 67% (preset by the user). 





This temporary caching would continue for as long as the 





handheld device was signed on to the network. If the device 





was to be recharged and the battery level increased, all the 


26 





cached information is automatically un-cached and shared. 


And as a failsafe, the handheld device is automatically 





signed off of the network when the battery level falls below 





30%. At this time, the data that was temporarily stored or 
"cached" on the portal was copied and delayed from further 


sharing until the user was logged onto the network again. 


(3) Voice and musical imprints were recorded to 








indicate when the TwiddleNet Client is added to the 
TwiddleNet network, when data was sent, and when data was 


received. The following depicted each auditory signal: 


(a) Handheld device added to TwiddleNet 


Network: pre-selected music. 











(b) Data sent: "Message sent." 
(c) Data received: "Alert received." 
(4) Along with auditory signals, written 


verification was shown on the screen of the handheld device: 


(a) Handheld device added to TwiddleNet 





Network: 'Signed in' or 'Signed out.' 
(b) Data sent: 'File sent.' 
(c) Data received: 'File received.' 








(5) A new graphical user interface (GUI)° feature 


was implemented to specialize in treatment during medical 





triage operations. This GUI allowed for additional and 


specific tagging of each "patient" to be added at the 








generation of the content. This GUI provided the freedom to 





5 GUI- Graphical User Interface. A visual way of interacting with a 
computer using items such as windows, icons, and menus used by most 
modern operating systems. 


27 





input basic patient information, i.e., name, ID number, age, 





gender, etc. by utilizing the touch screen keyboard or 
smartphone keypad and a series of pull down menus. Further 


specification of patient ailment(s) could be depicted by a 








separate screen presenting the image of a body (front and 
back) and by utilizing the touch screen, the user could 
indicate which body part(s) were injured/affected. 


Additional tabbed screens allowed for indication of basic 








treatment, i.e., bandage, splint, etc and what types of 





medication, if any, were administered. All information on 





each GUI screen could be keyed in by utilizing a combination 





of the touch screen keyboard, smartphone keypad and/or pull 


down menus. These GUI screens offered an extremely easier 








interaction between user and smartphone to facilitate and 


enhance triage operations during any humanitarian 





assistance/disaster relief (HA/DR) missions. 


2. Cons 


Although this version of the TwiddleNet application is 
very robust and successful on many levels, there continue to 


be several converse issues present. 


a. Operational 


When taken out into the field, the design of the 





hp iPAQ phones lacks the ruggedized and streamlined features 





that users would find helpful and sometimes necessary during 





HA/DR missions. Thes features are listed but not limited 





EOS 


(1) No ruggedized case to protect from 


accidental abuse. 
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(2) No waterproof or water resistant 


coating. 

(3) Hands-free capability - no attachment 
for lanyard. 

(4) Small viewing screens. 

(5) Unable to use touch screen with gloved 





hands - must use stylus. 





(6) Unable to take rapid photos —- Noticeable 
delay. 


(7) Built-in flash very small - Must have 





additional light source when taking photos at dusk or in the 


dark. 


b. Design 


(1) The TwiddleNet clients continue to 'freeze 





up' and display error messages when several photos are taken 
in quick succession and automatically uploaded onto the 
TwiddleNet Portal. At times, one or more files of captured 
data would not reach the portal and therefore would not be 
shared to awaiting recipients. The only solution to this 
issue was to reset the TwiddleNet Client and reconfigure 


back into the TwiddleNet Network. 


(2) The above design flaw uncovered an additional 
design issue that involved the TwiddleNet Client's inability 


to self-correct incidences of "multi-threading.' 








Specifically, when a TwiddleNet Client lost connectivity 








during data capture, the original IP address given to that 





specific TwiddleNet Client would still be ‘in  use.' 
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Therefore, upon reset of the 'frozen' TwiddleNet-Client, the 


server and portal were unable to associate or recognize the 





TwiddleNet-—Client upon re-associating back into the 








TwiddleNet Network. This error would create an, "open 





thread' that the TwiddleNet Portal would continually search 
for and therefore would never recognize the original 
TwiddleNet Client as logging back in. The solution for this 
flaw was based on a coding issue that had to be corrected at 


the programming level. 


F. CHAPTER SUMMARY 


The TwiddleNet system came from the realization that 





field work needed a more streamlined communication platform 
in which to capture and share data in areas where no 


communication infrastructure existed. Leveraging the 








ubiquity and power of today’s smartphones allowed the 


creation of an autonomous, self-contained adhoc network that 





allows the capturing and dissemination of field data within 





minutes of scene arrival. 


Although the first three iterations of TwiddleNet were 


plagued with various operational and design issues, it has 





allowed sound incremental improvements that have steadily 
paved the way for the more stable Fourth Generation 


TwiddleNet. 
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III. DETERMINATION OF METRICS AND FEASIBILITY OF 
USE: FIRST THREE ITERATIONS 


A. OVERVIEW OF APPLICABLE AREAS OF USE 





Deploying a damage assessment system for information 











gathering after a disaster or in response to a DoD operation 
is imperative within the first 48-72 hours. Any 


information, data, facts or knowledge gathered during any 





operation is extremely time sensitive and oftentimes 











cumulatively relative to previous data. Distortion of these 








facts caused by flawed data collection or inaccurate 


information serves to only compound an already confusing and 





frequently extremely volatile and dynamic environment. And 





with the Normative Decision Making Theory® prescribing the 


conditions under which leaders should make decisions 





autocratically, or with other decision makers, it assumes 











the following: Individual decision are more tim ffectiv 








than group decisions, subordinates are more committed to a 





decision if they participate in its formulation, and 


complex/ambiguous tasks reguire more information and 





consultation for reaching high-quality decisions. There is 
no space to accommodate the ill effects of faulty data 
collection, producing a domino effect that would easily 
contaminate and degrade the clarity of the knowledge gained 


after processing the data. 





6 Normative Decision Making Theory- Proposed by the Austrian-American 
sociologist Peter Blau (1918-2002), the Normative Decision Making theory 
prescribes th conditions under which leaders should make decisions 
autocratically, or in consultation with the group members, or with group 
members fully participating. 
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Competent fact gathering and dissemination in an 





environment based on collective reasoning is difficult when 





faced with barriers and challenges that accompany any 





natural, accidental, or willful disaster. Fact based 





opinion, devoid of preconceived stereotypes and bias is what 
is needed by a successful command and control, and this can 


only be achieved by specially trained first responder 





personnel and intelligence organizations that can gather and 
disseminate appropriate information to the decision makers 


of each military mission. 





As mentioned earlier in this thesis, the primary use of 





the TwiddleNet application was to harness the technological 
power of today's smartphones and incorporate them as the 


primary tool for gathering and disseminating information and 





data during the rapid formation of '‘'on-the-fly' networks 





when deployed for humanitarian aide, disaster relief, or 


large urgent projects. 


The ubiquitous presence of today’s smartphones are not 
limited to just telephonic communication, but rather they 


are recognized as portable personal computers (PCs) with a 





variety of communication capabilities. More powerful than 
their counterparts a decade ago, the content capture and 
communication capabilities have paved the way to a broad 


array of new services. Aside from their basic voice, text, 





and email capabilities, it is now possible for these mobile 


gadgets to provide video conferencing and streaming 
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multimedia. Further technical advances have dramatically 
increased the picture quality and the multimedia message 


service (MMS)?7. 


With these multi-media enhancements, the ability for 
the TwiddleNet application to be deployed for any fact 
gathering or triage mission utilizing commercial off-the- 
shelf (COTS)® technology makes this system not’ only 
inexpensive to obtain and maintain, but familiar and user 


friendly. 


The TwiddleNet application was designed to support and 
incorporate the advanced, real-time, file sharing in a 


secure network environment; to be deployed and create a WiFi 





cloud in which to capture and disseminate valuable 


information within the first crucial 48-72 hours, to 





disseminate data for further processing by Command and 





Control (C2) centers and support medical agencies. 


The historical destruction caused by such disasters as 





Hurricane Katrina is an ideal scenario in which to exhibit 


the positive potential of the TwiddleNet application during 








a humanitarian assistance or disaster relief scope. In the 


wake of Katrina, the communication infrastructure was 





completely devastated, and there remained th xplicit need 


for communication in order to organize and synchronize 








relief efforts. The nature of this scenario (detailed in 





7 Multimedia Message Servic Where media messages are sent like text 
messages using the telephone infrastructure or by uploading the message 
content onto Web pages using a regular PC. 


8 COTS- commercial off-the-shelf. A term for software or hardware, 
generally technology or computer products, that ar ready-mad and 
available for sale, lease, or license to the general public. They are 
often used as alternatives to in-hous developments or one-off 
government-funded developments. 
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Chapter VI: Scenario/Experimentation and Results) permitted 





the TwiddleNet application to deploy as a Mobile Emergency 
Command Post to create an autonomous WiFi network within the 
affected area, collecting environmental data and medical 


information during the triage of survivors, and further 





information dissemination to the C2 center. 











In addition to facilitating first response and disaster 








relief, the TwiddleNet program can be deployed with military 


patrol units or surreptitious "cloak and dagger" fact 








gathering missions to gain photographic/video graphic data 


for dissemination to the C2, thus providing basic 





Situational awareness of the target individual(s) or area. 





Due to the ubiquitous and international existence of the 





many styles of the smartphone, taking photographs and video 





during a covert mission is easily accomplished. 


Only customized coding and implementation limit other 


applications for the TwiddleNet program, external to the 











DoD. As discussed by Ableiter [2], Social Networking 





capabilities to broadcast important and real-tim vents, 








i.e., the birth of a child and all pertinent details, to 
family and friends, without having to make a number of 


individual calls via a single point of contact or a pre- 

















planned phon tree; liminating the need to take upload 
photos and video to pre-existing Web sites and a later time 


or date. And beyond telecommunications, texts, and email, 





TwiddleNet offers the ability to disseminate group alerts 


for medical reasons, providing current and real-time updates 
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or an expanded version of Twitter? where parents can follow 
the events in their children's lives, but within a secure 


and private network. 








Within the commercial world, Internet based advertising 


has become a forward marketing tool. With the utilization 





of TwiddleNet, advertisers could disseminate advertising 








specials to consumers, sending notification of real-time 
sale exclusives that would persuade the consumer to purchase 
the sale item, or at the very least, draw them into the 
advertiser's retail venue, in the hopes of leading to more 
purchases. The ease of tracking consumer-purchasing habits 
and utilizing this information to customize marketing alert 
messages should have great appeal to today's commercial 
advertisers, giving the TwiddleNet program a practical use 


in the business world. 


B. METRICS OVERVIEW 


The objective of this project was to test all 
iterations of the TwiddleNet application after each 


modification, to document all system improvements and 





deficiencies, and to definitively confirm the validity and 


usefulness of the application. 





There were several Measures of Performance (MOP)1° and 


Measures of Effectiveness (MOE)!!! that were considered 


9 Twitter- Twitter is a privately funded startup with office in SoMA 
neighborhood of San Francisco, CA. Started as a side project in March 
of 2006, Twitter has grown into a real-time short messaging service that 
works over multiple networks and devices. 


10 MOP- Measure of Performance. Thes ar xpressions of a 
quantitativ (objective) "operational" measure that is a key indicator 
of task accomplishment. 
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during the testing and analysis of all four TwiddleNet 








iterations. Thes measures wer developed to test the 





TwiddleNet hardware and software under various types of 
controlled environments and scenarios, different 
temperatures and weather conditions, and a range of handling 
procedures. This section specifies how the TwiddleNet 
performance data was collected and analyzed throughout my 


thesis research. The overall assessment strategy for 





TwiddleNet was to evaluat the Effectiveness, Suitability, 








and Mission Impact of the various components under 
physically demanding conditions with different network 


configurations. 








Pre-testing efforts consisted of: 








Establishing a baseline assessment of the 








TwiddleNet system operating in the present environment. 





2 Documenting environmental data (humidity, 


temperature, and foliage density), network radius and 





uncontrollable variables at the testing site (aka: 


Humanitarian Assistance scenario site). 


3h Ensuring mechanical setup, Startup/Boot and 


correct operation of system software. 





When TwiddleNet Handheld Clients wer deployed, 


verification of data successfully captured and disseminated 





among team members, the TwiddleNet Command Post and all 














remote C2 centers was conducted. It was also confirmed that 
11 MOE- Measure of Effectiveness. Thes ar pressions of a 
qualitative (subjective) “operational” measure that is a key indicator 





of task accomplishment. 
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all TwiddleNet data and images backhauled to the Joint 
Operations Control Center (JOCC)!4% were continuous’ and 


clear. 


Assessment of radius distance between TwiddleNet team 








members and the TwiddleNet Portal, TwiddleNet Portal and the 


TwiddleNet Command Post, and TwiddleNet team members wer 











done to evaluate continuous data sharing and dissemination. 


The final stages of testing, in consideration 


exclusively of TwiddleNet Fourth Generation (described in 





Chapter IV), consisted of the "group-sharing" feature and 
the ability of the TwiddleNet Handheld Clients to 
associate/re-associate into the network once the TwiddleNet 
team member has traveled outside the TwiddleNet Network 


radius. 





This final portion also included investigating the 


effects of associated TwiddleNet Handheld Clients that are 





in "sleep mode' (not gathering data) in 15-minute 





increments. Verification that the Handheld Clients 





continued to be associated to the network, automatically re- 
associated back into the network post sleep mode period, or 


required manually re-association. 


The TwiddleNet proof of concept integrated the 
capturing and sharing of data between all TwiddleNet 
Handheld Clients, the TwiddleNet Command Post and all remote 


network locations via the TwiddleNet Portal distribution. 








12 gocc- Joint Operations Control Center. A central area that boasts 
of rapid deployment capabilities, increased operational capability, 
enhanced situational awareness, and a comprehensiv view of the 
battlespace; all designed into a high performance, low-risk system that 
enable decision superiority at all levels, and in all domains. 


Si 











The resulting system demonstrated reception and display of 





TwiddleNet data at local and remote C2 centers. The main 





objective of the TwiddleNet testing team adhered to was to 


test the TwiddleNet system in various realistic scenarios 





and controlled lab environments for th determined 
performance measures to evaluate the system's utility and 


capability in an operational context. 


Toward that end, measures and data sources address the 











Critical Operational Issues (COIs)13, Objectives,!4 and 





MOES/MOPs, as well as a data collection and analysis 


approach. 


1. Overview 


To evaluate the Effectiveness and Suitability of the 
TwiddleNet capability, testing gathered objective data from 


equipment readings and subjective data in the form of user 








feedback. The Information Architecture (IA) relied upon 





Data Collection spreadsheets, Computer Screen Captures, 
Event Logs, and data collector observations during the 
Technical Capability Assessments (TCA) and Operational 


Capability Assessments (OCA) event. 








During OCA events, TwiddleNet users were asked to do 


the following: 


a. Set up TwiddleNet system. Associate into local 





network using static IP addresses. 





13 CoI- Critical Operational Issues: Phrased as a question and must 
be answered in order to properly evaluate operational effectiveness, and 
operational suitability. 








14 Objectives-— Statements that break down the COI into clearly 
defined manageable tasks and are developed to group or organize the 
measures need to resolve the COI. 
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bs Use TwiddleNet Handheld Clients to capture data 


when deployed. Track data shared using "group sharing and 





multiple streaming” features. 


on TwiddleNet teams traveled to specified distances 
to verify maximum distance and range parameters for data 
sharing and dissemination to team members, the TwiddleNet 


Command Post, and the C2 centers/JOCC. 


om Evaluate TwiddleNet Handheld Clients" capability 





for continuous connectivity or automatic re-association into 


the network. 


e. Review data collected through various scenarios 


and controlled environments. 


2. Data Management and Analysis 


General data management functions were distributed 


among the members of the TwiddleNet Team and consisted of 





the following: 














a. Identification of data requirements. 
ion Data collection. 

ons Data reduction and analysis. 

d. Generation of analysis products. 

3. Database Development 


The TwiddleNet team used standard commercial word 
processing, spreadsheet and database software, Ti Seasy 
Microsoft Windows® Word, Access and Excel, to analyze and 


manage Computer and Event Log as well as data collected 
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during the testing periods. I developed and maintained the 


TwiddleNet master database for data reduction and analysis. 


4. Database Verification 








nsured the completeness, accuracy and quality of the 





data stored in the TwiddleNet database. Each member of the 
TwiddleNet team was responsible for reviewing their event 


logs and test data, annotating the notes where necessary. 





The data was annotated in the database at the conclusion of 





the day's testing events, or as soon as able. I reviewed 








the completed database to ensure data accuracy. 


5. Database Processing and Analysis 





Data was entered directly into the TwiddleNet database 

















whenever feasible. Data collectors were trained in data 
entry procedures and all data wer ntered at the end of 
each day. Data entered into or transferred to electronic 








storage was backed up using portable media devices. 


Cc. SYSTEM ARCHITECTURE 


TwiddleNet is a program that exploits the power of 


today's COTS smartphones to create mobile personal servers 





that "serve up" real time information for sharing among 





awaiting recipients. This architecture employs various 
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communication modes, i.e., WiFi, GSM/CDMA!5, GSPRS/EDGE!$, 
WiFi 802.11b and Bluetooth, which are standard within these 
smartphones to support a rapidly deployed adhoc network and 


a dependable data-sharing infrastructure. 


The main components of the TwiddleNet architecture are 


the Client, the Portal, and the Command Post. 


1. Client 





TwiddleNet system has been utilizing th Hewlett 
Packard iPAQ hw 6945 Mobile Messenger Smartphone for testing 
purposes (figure 2). The iPAQ hw 6945 comes standard with 


the following specs [6]: 


a. Integrated Antenna. 























lore Integrated Quad band GSM/BPRS/EDGE wireless’ radio 


with automatic band transition. 





@: Integrated GPS Receiver. 

















d. Integrated Wi-Fi (802.11b). 





15 GSM- (Global System for Mobile communications) is the most popular 
standard for mobile phones in the world. GSM is used by over 3 billion 
people across more that 212 countries. Its ubiquity makes international 
roaming very common, enabling subscribers to use their phones all over 
the world. GSM differs from its predecessors in that both signaling and 
speech channels are digital, and thus is considered a second-generation 














(2G) mobile phone system. CDMA- (Code division multiple access) is a 
channel access method utilized by various radio communication 
technologies. It employs spread-spectrum technology and a_e special 


coding scheme (each transmitter is assigned a code) to allow multiple 
users to be multiplexed over the same physical channel. 














16 GPRS- (General packet radio service) is a packet oriented mobile 
data service available to users of the 2G cellular communication systems 
GSM, as well as in the 3G systems. In 2G systems, GPRS provides data 
rates of 56-114 Kbit/s. EDGE- (Enhanced Data rates for GSM Evolution) 
is a backward-compatible digital mobile phone technology that allows 
improved data transmission rates, as an extension on top of standard 
GSM. EDGE is considered a g radio technology and is part of 
International Telecommunications Union's 3G definition. 
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e. Integrated Bluetooth 1.2 wireless technology. 

f Intel PXA270 Processor 416 MHz. 

om Integrated HP Photosmart 1.3 MP Camera. 

h. Integrated alphanumeric keyboard. 

ee Integrated miniSD slot (memory only). 

Jie Removable/rechargeable 1200 mAh 3.7 Volt, Lithium-— 


ion battery. 


k. Microsoft Windows® Mobile 5.0 for Pocket PC, Phone 


Edition, with Messaging and Security Feature Pack. 


1. Mobile versions of Microsoft Windows® Office 





software include (Word, Excel, PowerPoint, and Internet 





Explorer). 
| 
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Figure 2. iPAQ hw 6945 Mobile Messenger Smartphone. 





Each TwiddleNet team member is given their own HP iPAQ 
hw 6945 which utilizes the Microsoft Windows® Mobile program 
to run the TwiddleNet application, coordinating 
communication between all the components. Upon logging into 
the TwiddleNet network, each handheld device is assigned a 
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specific and unique IP address from the TwiddleNet DHCP 


server, automatically giving the content creator a specific 





tag. Alternately, the TwiddleNet client can also _ be 





assigned a specific IP address that can be hard coded into 








the smartphone. This is usually done when the local adhoc 





network has assigned a specific block of IP addresses for 
the exclusive use by the TwiddleNet team. All metadata 


files are instantaneously tagged with the content creator's 





specific tag and IP address. 


After logging into the system, the client has three 


utilities: 


a. Allowing the TwiddleNet member to instantly create 


metadata, capture images and photos (utilizing the 1.3 MP 





camera) and disseminate to th ntire team. 


be Alerting the portal of immediate availability. 








Ck Offering a basic interface for the team member to 
accept and download any metadata files created by other team 


members. 


All TwiddleNet team members are deployed with the 





TwiddleNet Portal (Figure 3) to gather and disseminate data, 


functioning as either personal content servers or personal 





content requesters. This role exchange is automatic, easily 








accomplished and transparent to the team member. 
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Figure 3. Basic TwiddleNet Infrastructure w/handheld 








acting as the Portal. 


2. Portal 


For all iterations of the TwiddleNet system, the OQO 





Ultra Mobile PC (Figure 4) has been utilized as the main 
Portal component, and the HP iPAQ hw 6945 smartphone as an 
alternate option. The OQO0 Ultra Mobile PC is a fully 


functional Windows PC small enough to fit in your pocket, 





yet powerful enough to rival a regular laptop. It comes 


standard with the following specifications [7]: 


a. OS: Microsoft Windows® XP Professional. 
b. 1GHz Transmeta Crusoe Processor. 

CG. 30GB hard drive (shock-mounted). 

d. 512MB DDR RAM. 
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=o 800 x 480 


(indoor/outdoor readable) 








W-VGA ona transflective display 








fey 3D accelerated graphics with 8MB of video RAM. 

g. 802.11b wireless. 

h. Bluetooth wireless. 

iy 4-pin FireWire (1394)/USB 2.0. 

lire 3.5mm stereo headphone jack/microphone/speaker. 

k. Battery life up to three hours. 

alts Weight: 14 ounces. 

m. Accessories: Universal power supply, docking 


cable, desktop docking stand. 


n. For input/navigation: Thumb keyboard with 


TrackStick, mouse buttons, and thumbwheel. 








Figure 4. a. OQO Ultra Mobile PC. b. OQO Ultra Mobile 


PC w/] 





Docking Station. 
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Client 3 Client 4 








Figure 5. Basic TwiddleNet Infrastructure w/OQO as Portal. 


The TwiddleNet Portal (shown in Figure 5) acts as a 
type of gateway for the TwiddleNet network, monitoring when 


clients log in and out of the system, receiving and storing 





all metadata and content generated by all the users, and 
disseminating/"pushing" to all team members instantaneously 
or when a user "pulls" the information at a later time. The 


Portal also stores all "tagging" information for all 








TwiddleNet Clients logged into the system, tracking all IP 


addresses currently in use. 


3. Command Post 


Currently, the TwiddleNet Command Post program 
functions on a Linux laptop, but can be run on any Windows 
laptop or desktop computer. When specified by the 


individual Clients, the Command Post will receive all 





metadata alerts and can also retrieve or "pull" all content 
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files that are being temporarily stored by the Portal. It 
then displays all downloaded content on the Web display page 


in sequential order of receipt. Fach data file is 





automatically tagged by the specific content creator and any 


other specific information, inputted by the user upon data 





creation, is also shown. The Command Post also has the 
ability to manually update each data file, at any time, with 


additional information beneath each displayed image. 





The Command Post is typically left at the JOCC or C2 


location to generate increased information superiority. 





Through Network Centric Warfarel’ [8] utilities, the 
deployed users can "push" data from the affected area to 
mission commanders to achieve shared awareness and a level 


of synchronization for all decision-makers. 


Alternatively, the Command Post can also be deployed 





with the TwiddleNet Clients and Portal to the affected area 
and be linked to the JOCE/ C2 via backhaul link 
communications or  SATCOM (satellite communications) 18. 
Regardless of whether the Command Post is deployed or not, 


any computer system operating within the same WiFi network 








as the TwiddleNet system can access all data and photos on 





17 Network Centric Warfar A term developed to describe the way the 
DoD would like to organize and fight in the Information Age. The former 
CNO, ADM Jay Johnson, has called it "a fundamental shift from platform-— 
centric warfare." In essence, NCW translates information superiority 
into combat power by effectively linking knowledgeabl ntities in the 
battlespace. 

















18 SATCOM- Satellite Communications. A family of communications 
satellites originally developed and operated by RCA American 
Communications (RCA Americom) [11]. An artificial satellite that is used 
to help telecommunication by reflecting or relaying signals back from 
space and back down to Earth. It is the most powerful form of radio and 
it can cover far more distance and wider areas than other radios. It 
can also communicate with words, pictures and other forms of 
information. 
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the Command Post database. Opening a Web browser on the 





specified computer and typing in the IP address of the 
TwiddleNet Command Post laptop will accomplish this. Figure 
6 iS a screen capture of the TwiddleNet Command Post 


display. Note that basic information of the photo is 





displayed just underneath the captured image. 











TwiddleNet Command Post - Windows Internet Explorer -l2/x/ 
€) “ye €. http:/flocalhost:8080/ ¥ I) #4) |X| JLive Search Pi 
File Edit Yiew Favorites Tools Help 
we w& (@TwiddleNet Command Post | | fp) > Bl ~ Spy fb Page + Tools + a 





" TwiddleNet Command Center 
=. Nil hy ‘Author + 
od are —— 


Automatically update content? 





search | 


@ Yes 
CNo 





Ba 
[Done | | TI 1] Le) Local intranet [100% ~ 4 


@® start! | @ GO G | I Manage Your Server ® pucp a) Formi | @ TwiddleNet Command... [PS O@ Yy 11:17 am 








Figure 6. TwiddleNet Command Center screen display. 


D. NEWLY DESIGNED DATABASE 








The newly designed Portal Database was created by LCDR 
Todd Glidden [4] and is featured in the 4th iteration and 
fully described in Chapter IV. Critical to the TwiddleNet 








program design, the Portal Database warehouses system data, 











to include user identification, device and component data, 


48 





IP addresses, temporarily stored metadata, and group 


membership classifications. Because of continued errors 





with multithreading, group sharing, and associated issues 








with network congestion, Glidden recognized the need to 


upgrade the Portal Database design. 





Glidden re-constructed the database design, utilizing 


formal database design methods, to include Entity- 





Relationship (E-R) and Relational modeling. The major 


elements of the new database are [9]: 


les Portal User Table. This contains user 


identification that is critical for verification when the 





user signs in and for linking users to groups (to track 





group membership). This element is fundamental to the user- 











partitioning feature introduced in the 4th iteration. 





2. Belongs To Table. Routes users to groups by 


linking a unique user identifier listed in the Portal Users 








Table with a unique group identifier stored in the Groups 





Table. This tells the Portal which users belong to which 





groups so that alerts and data dissemination can be properly 


sent to the specified group(s). 


3:3 Groups’) Table. This links the user with his 
specific handheld device. This is accomplished by linking a 


unique identifier for the user from the Portal Users Table 











with a device identifier in the Devices Table. The IP 








address of the user's device is stored and can be retrieved 





by the Portal from the Devices Table. 





4. Devices’ Table. Stores critical identification 








information, to include IP addresses, for all handheld 
devices signed onto the TwiddleNet system. 
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Be. Content Info Table. Stores the metadata 





associated with shared data/information. 


6. Special Tags Table. This is designated to store 


Situation-specific data, as established by the system 





administrators and mission planners deploying the TwiddleNet 











system. Currently, this table stores medical triage data as 


detailed in [2]. 


The database management system used for this upgrade 
was MySQL. As specified by Glidden, the decision to use 


MySQL was based on the following: 


1. It is an open-source and freely available. 








2. It allows for easy administration through the use of 


tools such as phpMyAdmin}! [10]. 





As detailed in the System Operation (Chapter IV) the 





MySQL must be activated during the sign-in process of the 


Portal to begin the gateway functions. 





19 PhpMyAdmin- An open source tool written in PHP intended to handle 
the administration of MySQL over the World Wide Web. It can perform 
various tasks such as creating, modifying or deleting databases, tables, 
fields or rows; executing SQL statements; or managing users and 
permissions. 
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IV. FOURTH ITERATION 


A. OVERVIEW OF OLD AND NEW TWIDDLENET OPERATION 





In previous iterations of TwiddleNet, the users or 


content creators were all members of the same group or team; 





users wer defined and delineated only by their 








identification tags. However, in the fourth iteration or 





Fourth Generation TwiddleNet, Glidden expanded the 





TwiddleNet virtualization operation to include a group 





partitioning application and content privacy. Through his 
research and coding development, Glidden presents in his 
thesis, "Privacy for Mobile Networks via Network 


Virtualization, "[9]: 


The use of mobile devices and mobile networks to 
[define and expand] a network virtualization 
technique in order to provide content privacy 
protection. This allows TwiddleNet users to 
share content on a per-group basis among virtual 
networks of user groups. It was found that this 
virtualization technique successfully provided 
content privacy protection from the threat of a 
casual observer [9]. 
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Figure 7. Old TwiddleNet Operation. 


Figure 7 illustrates the old operational layout of 


TwiddleNet Generation(s) 1-3, utilizing the local adhoc WiFi 





802.11b network generated by the mission C2/JOCC. As shown 
here, all TwiddleNet clients are functioning within one 
group construct, sharing all information among all team 
members and the Command Post via the OQO Portal. (Note: 


When operating within the C2 adhoc WiFi network, pre- 





ordained static IP addresses are set aside for the explicit 








use of the TwiddleNet Team(s). All IP addresses are hard 
coded into each component, with the Command Post and Portal 


always programmed with the first two addresses.) 


52 


WiFi 802.11b_ 





Figure 8. New TwiddleNet System Operation w/Group 
Partitioning. 


As Figure 8 illustrates, each content creator is a 
member of a specific group: Team l1(a/b), 2(a/b), or 3(a/b). 


This is chosen upon sign in of that particular handheld 





client. Team members can specify which team(s) will be a 
recipient(s) of their metadata to include the Command Post. 
For example, if Team la member(s) desire to share content 
only with members of Team 3b and the Command Post, these 
recipients would be chosen during the sign in process. When 


Team la members create their metadata, it is sent to the 





Portal, which sends alerts and shares the data with only 





Team 3b members and the Command Post; the other Teams are 
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not alerted and therefore will not have access to the 





information. After receiving an alert, the recipient(s) may 


download the file instantaneously or at a later time. 


Furthermore, if a Team la user(s) desires to change 





recipients during exploration and data collection, this can 





be accomplished by returning to th "Recipient Options" 


screen without requiring signing out and/or signing in. The 








upgrade in the Portal Database allows this streamlined group 


partitioning to function smoothly and seamlessly, the user 





simply making use of a basic GUI (Figure 9), selecting the 








box of specified recipient(s) with the stylus and touch 








screen. The default box is always the team that the user 





belongs to. For added convenience, there are also two other 


boxes labeled "All" or "None." 


Within the user-partitioning feature, teams are 








explicitly labeled as: 











dls Team l(a) (b)- Medics. 

2. Team 2(a) (b)- Fire Fighters. 
3:2 Team 3(a) (b)- Police. 

4. Command Post. 
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Figure 9. TwiddleNet Client Recipient Options screen. 


There is no limit to the number of handheld 


clients/users within each team. 


The second noteworthy advance in Fourth Generation 
TwiddleNet is the content privacy stemming from the user- 


partitioning feature. With the ability to specify which 





team members can receive the information, safeguards the 
information collected. For example, members within the 


Medics Team will be collecting personal patient information, 








i.e., Name, age, identification/SS number, etc. that does 
not need to be shared with members of the Fire Fighter and 
Police team. Concurrently, Medic team members would not 
find it necessary to know of any illegal proceedings, i.e., 
looting/burglary, going on in a different part of the 


affected area. 


The third noteworthy advance within Fourth Generation 
TwiddleNet is the advent of the TwiddleNet Gateway 


component. The TwiddleNet Gateway was a piece of new 





interfacing software, placed on a separate Dell laptop, 
which allowed content sharing and receipt from other 


external sources, i.e., the Command Post. The Gateway could 
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also "push" data and information to all the TwiddleNet 
users, utilizing the same group-partitioning feature, 
specifying who would receive the information. The 
TwiddleNet Gateway could be as close as within the mission 


JOCC/C2, or as far away as a different city, state, or 





country. In these instances, connectivity would have to be 


generated by SATCOM. 


wh SATELLITE 
. 







Local 4.” ir 
Network .. q 
: — 
NPS 
EXTERNAL SYSTEM 
SIMULATOR * 
Affected GATEWAY _ 
ite 
Figure 10. Advanced TwiddleNet Layout w/SATCOM and Gateway. 


Figure 6 shows the advanced layout of the TwiddleNet 
system during a complex operation. Within several WiFi 
adhoc networks generated by several access points, several 
TwiddleNet teams are deployed into the affected area(s) 


(i.e., Thailand, New Orleans), generating and gathering data 
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that is sent to the deployed TwiddleNet Portal, which in 








turn, sends alerts to the other team members and to the 
command post. Fach JOCC and external Gateway site (i1.e., 
NPS- Naval Postgraduate School) can access all data sent to 
and from the command post via connections generated by 
backhaul links and SATCOM, providing far-reaching 


capabilities anywhere in the world. 


1. Implementation Tools 


The software programming language used for all the 


TwiddleNet iterations was C#. The TwiddleNet Portal code is 





based on the .NET 2.0 Framework intended for PC integration. 











The TwiddleNet Client coding is the Pocket PC application, 
supported by the .NET 2.0 Compact Framework, intended for 
use by devices running Windows Mobile 5 operating system 


(OS). 





Microsoft Windows® Visual Studio 2005 Integrated 





Development Environment® was employed during the TwiddleNet 
program development. This was due to the ease of use, 


translation and integration for the C# language. 








Furthermore, Visual Studio was an excellent integration tool 








with the Pocket PC Softwar Development Kit, providing a 
powerful standard for the Client development, offering 
additional tools for easy code transference and device 


testing. 





As mentioned earlier, MySQL Database Management System 


was utilized to accommodate the TwiddleNet Portal database 

















(refer to Chapter , pg. 46). This management system 
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incorporated the XAMPP29 cross-platform Web server for ease 











of implementation and testing. It also allowed the use of 





phpMyAdmin for a convenient interface for the MySQL 
database, resulting in a simplified management tool for the 


TwiddleNet Portal database. 


2. Fly Away Kit 


With all iterations of TwiddleNet, the consistent theme 





was the ability to be quickly deployed and easily 


established with efficient ease. With this in mind, the 





creation of the TwiddleNet Fly Away Kit (FLAK) was 
accomplished and perfected. With the simple addition of a 
COTS Cisco Aironet Wireless Access Point (Figure 11), the 
TwiddleNet System became completely autonomous; capable of 
deploying, creating a private and encrypted WiFi network, 


and gathering and disseminating information within 20 





minutes of on-site arrival (thoroughly explained in Chapter 





VI: Experimentation and Results). The TwiddleNet Access 








Point transmits 802.1lla/b/g, and is designated as the 


TwiddleNet Mobile Network. 





20 xAMPP- A free and open source cross-platform Web server package, 
consisting primarily of the Apache HTTP Server, MySQL, and also 
translates code written in the PHP and Perl program languages. Leis 
designed to allow programmers to test work on their own computers 
without Internet access. 


58 


Figure 11. Cisco Aironet Wireless Access Point. 


The TwiddleNet FLAK, encased in a single, medium sized, 
portable Pelican Case Product#!, stores and protects the 


following TwiddleNet hardware components: 


1. 10 Clients (w/desktop charging stations and power 





cords). 


Ze 1 OQO Ultra Mobile PC (w/desktop charging station 


and power cord). 








3% 1 Linux laptop and power cord (Command Post). 
4. 1 Dell laptop and power cord (Gateway). 
5 1 Cisco Wireless Access Point (w/power cord and 4' 


CAT 5 cable). 
6. 4 8-outlet surge protectors/power strips. 


The Pelican Case (pictured in Figure 12) is tactical, 
logistical and durable, airline and Transportation Security 


Administration (TSA) approved, making this an ideal 


21 Pelican Case Products- Pelican Products is a global manufacturer 
of advanced lighting system, rugged protector cases and shipping 
containers 
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transport container. All components are 110v/220v 


compatible, allowing deployment to other countries possible. 








Figure 12. Pelican Case w/Customizing Padding. 


B. NEW TWIDDLENET SYSTEM OPERATION AND SETUP PROCEDURES 


This section provides a step-by-step guide for the 
complete preparation and implementation of the TwiddleNet 
System. With this complete and detailed guide, training of 


any new user could be accomplished within one hour. 


1. Create the WiFi Cloud 

a. Plug in and power up the Linux laptop/Command 
Post. 

bus Connect the TwiddleNet Cisco Wireless Access Point 


with the blue CAT 5 cable. 


Cx Connect the TwiddleNet Access Point power cord 


into the surge protector/power strip. 


2. Setup of the Portal 


a. Plug in and power up the OQO Mobile PC. 


60 


By Ensure that it is connected to the TwiddleNet 





Mobile Network and is assigned the following IP address: 





192.168.1.3. 
Gs Scroll to the bottom icon “XAMP.” 


(1) Start “XAMP.” 





d. Double click on the TwiddleNetServer icon. 





(1) A command window pops up and states that the 





server is running. 





(2) If this does not occur, verify WiFi 


connection and then double click the TwiddleNetServer icon. 


3 Command Post Setup 





a. Verify that the Portal (OQ0 or client) IP Address, 


within the TwiddleNet Mobile Network, is listed as: 








196.168.1.3. 
b. Double click on the Command Post icon. 
(1) The Command Post screen will display. 
(2) Press the "Start" button at the bottom of the 








screen only once. 


(3) The screen should display "Waiting for 


alerts.” 





Gk Open the Internet Explorer browser and type, 





"www.localhost.8080" in the browser line (should 








be in the history pull down menu). 


(1) The displayed page is probably an old page, 





so once you have taken a test photo, the screen will refresh 





automatically. If not, press the "refresh" button. 
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4. Setup of the Client 





NOTE: Prior to the start of any mobile device, ensure 


that all other service components are running properly. 


a. Power up handheld device (power button located on 


top right of smartphone). 
Bis Verify association to correct network. 


(1) Press the WiFi "iPAQ wireless" tab. 





Figure 13. WiFi iPAQ wireless tab screen. 


(2) Press "View WiFi Networks.” 





Figure 14. iPAQ Screen "View WiFi Networks.” 


(3) Click once on the specific network name. 





Figure 15. iPAQ Configure Wireless Networks screen. 





C. Adding a New Network on the iPAQ wireless. 


(1) Return to the iPAO wireless screen. 





Figure 16. iPAQ wireless tab screen. 


(2) Press "View WiFi Networks.” 





Figure 17. 1PAQ "View WiFi Networks" screen. 


(3) Click once on "Add New..." 





Figure 18. iPAQ Configure Wireless Networks "Add New..." 
screen. 





(4) Type in the new Name, then click on the tab 


in the center of the screen that reads "Network 








Key.” 
Figure 19. iPAQ "Configure Wireless Network" screen w/Network 
Key tab. 
(5) Select the appropriate Authentication and 





Encryption. 


Figure 20. 


Figure 21. 





iPAQ "Configure Network Authentication" screen. 


(6) NOTE: For "TwiddleNet" and "TwiddleNet 
Mobile" networks, the Authentication is "Open" and 
the Encryption is "WEP.” Ensure that the tickbox 


underneath is not selected. 


(a) Enter the network key "927e31e9b8" into 
the field. 


(b) Click "OK" on the top right of the 


screen. 





(c) If it does not connect, try re-entering 


the key, turn WiFi off and on again. 





iPAQ "Configure Network Authentication" screen. 
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d. If the DHCP (mechanism that automatically assigns 





IP addresses) is provided by the network, the Client should 





now receive an IP address. Verify by going to the iPAQ 


Wireless screen (Figure 22). 





Figure 22. iPAQ Wireless screen. 


(1) NOTE: For Advanced Users: Tf you know that 








you do not have DHCP service, get an IP address, 
network mask, default Gateway and DNS address from 


the Network Administrator. 


e. Return to the main screen (Figure 23). Turn on 
the WiFi by pressing the second grey button from 
the left only ONCE. 





Figure 23. iPAQ Main screen. 
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(1) The WiFi button will turn green once it has 





associated to the network with an IP address. 


(2) NOTE: If it does not turn green- check WiFi 





connection again. 


(3) NOTE: If it still does not turn green- 








verify that IP address (manual/automatic) is correct for the 


specific network being used. 


ies When connected to the network, return to the 


"Start menu" (Figure 24). 





Figure 24. iPAQ Start menu. 
g. Scroll to "Program Files.” 
falar Start TwiddleNet program. (Skip directly to 





"Start TwiddleNet"). 








aoe To manually enter a Fixed IP-Address: 


(1) Go directly to the iPAQ Wireless screen and 


select the "View WiFi Networks" (Figure 25). 
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Figure 25. iPAQ Wireless screen. 


(2) On the bottom of the screen, select the 
"Network Adapter" tab (Figure 26). 





Figure 26. iPAQ Configure Wireless screen. 


(3) Click on the WiFi Adapter (Figure 27). 





Figure 27. iPAQ Configure Network Adapter screen. 





(4) Select "Use Specific IP Address," and enter 


the IP-Address, Subnet Mask and Gateway. Then click on the 





"Name Servers" tab (Figure 28). 





Figure 28. iPAQ Wi-Fi Wireless Adapter screen. 





(5) Enter the DNS Server IP-Address and click the 





OK button at the top right corner of the screen (Figure 29). 





Figure 29. iPAQ Wi-Fi Wireless Adapter screen. 





(6) Read the text box (Figure 30): It means that 


you have to turn the WiFi off and on. 


(7) Click “OK.” 





Figure 30. iPAQ Configure Network Adapters screen. 


(8) Click "OK" until you are back at the main 








screen (Figure 31), then turn WiFi Button off and on. 





Figure 31. iPAQ Main Screen. 
Cc. STARTING TWIDDLENET 
Once all the TwiddleNet components are 
connected/associated to the selected WiFi network, 





TwiddleNet can be started. 





Once the "WiFi" button is green on the main menu 
screen, the User will select "Start." From the drop down 


menu, the User will then select "Programs." 
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2 From there, "File Explorer" will be chosen. Then 
the user must click on the down arrow to produce a drop-down 


menu. 


3. Selecting "My Device,” another drop-down menu 
appears, allowing the User to choose "Program Files," and 


then, "TwiddleNet_application." 








4. This selection leads to another drop-down menu, 


where "TwiddleNetCapp" is chosen to begin the TwiddleNet 





application. Figure 32 illustrates each step. 
(a) = (b) zee 
(Cc) ea (d) ate 


Figure 32. TwiddleNet Startup. 





1. Client Sign-in 


Fach Client must "Sign-in" to be recognized by the 





Portal and the TwiddleNet program. At the "SignInForm" 





screen (Figure 33), the User will enter the name of his/her 
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team, i.e., Team la, Team lb, Team 2a, Team 2b, Team 4a, 
Team4b. The password, associated to whatever team the user 
is assigned to, is then typed in, i.e., teaml, team2, team3, 


and team4. The Password is case specific, utilizing all 





lower case. 








Figure 33: SigninForm screen. 


When the user has successfully signed the Client into 








the TwiddleNet application, the German National Anthem can 
be heard. This indicates that the Client has successfully 
Signed into the Portal, the Portal has validated the Client, 





and written verification will also show on the Portal 


screen. When validation occurs, the Portal will store the 





IP address of the Client and also update the address to 





reflect the current user. (Incidentally, this is one way in 





which the Portal tracks the IP addresses of all active 


Clients). 





At this point, the Portal retrieves the group the user, 
"belongs to," in addition to all the groups utilizing 
TwiddleNet at that time. This information is then provided 
to each Client so that the Recipients can be selected for 


data sharing. 
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2. Recipient Selection 


After the sign in process has been successfully 





completed and verified via Portal verification and the 








completion of the German National Anthem, the User then 





chooses the Recipients. This is accomplished by selecting 





the box(es) of the appropriate Recipients (Figure 8): 


Medics, Fire Fighters, Police, Command Post, All, and None. 





D. SIGNING OFF FROM TWIDDLENET 








When the User completes testing and usage, the Client 








must undergo "Sign Off" procedures from the TwiddleNet 











application. 
ils Always delete all shared/received photos from the 
present testing session. This will keep the memory clear 








and battery life optimal. 


2a Always "Quit" TwiddleNet application on the 
Client. 
3s Always disconnect Client form the associated 


network by selecting the WiFi icon on the iPAQ Main Menu 


screen. (Ensure the WiFi icon is brown in color). This 








will also save battery life when the Client is in "Sleep 








Mode." 


4. Press the power button on the Client/Handheld 








Device to enter the smartphone in "Sleep Mode." 


Dis Verify written verification of Client “Sign Off” 


on the Portal screen. 
O- Command Post Sign Off 


a. Quit the TwiddleNet program. 
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ole Verify the Command Post, "Sign Off," on the 


Portal. 
Cx Power down the TwiddleNet laptop. 
7. Portal Sign Off 
a. "Stop" XAMP application. 
b. Quit the TwiddleNet program. 
Cs Power down the OQO component. 
E. RESETTING TWIDDLENET 
1. Client Freeze 





If the Client "freezes up," wait to see if the Client 
self corrects. The handheld device is sometimes slow, but 


will finish each application step one at a time. If the 





User is certain that the Client will not move any further, 
press the Reset button located at the bottom of the handheld 
device (Figure 34). This is called a, "soft reset." After 
this occurs, start the TwiddleNet application normally. 


(NOTE: Turning off the handheld device will not work). 





Figure 34. iPAQ Client Reset button. 
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Ze Application Reset 


To reset the whole application, delete the, 





"TwiddleNet," file (Figure 35). That will delete all the 
user settings and shared content. This should only be done 
if nothing else works. (NOTE: Never delete the file that 


starts the TwiddleNet application). 





Figure 35. TwiddleNet Application Reset- TwiddleNet File 
deletion. 
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V. TESTING DESCRIPTION: ITERATIONS 1-4 


A. CONTROLLED LAB TESTING 


All iterations were tested at the Naval Postgraduate 
School TwiddleNet Network Lab (Figure 36). At this 
location, a dedicated access point generated a stand-alone 
WiFi network, code named TwiddleNet. The access point, 


Command Post and Portal maintained dedicated IP address, 











while the Clients were issued dynamic IP addresses via the 





DHCP server. 


Additionally, presentations and demonstrations were 
conducted in this lab for potential research sponsors and 


general interest. 


~) 


— ‘ ~~, 


ACCESS POINT 802.11 
192.168.1.1 
\ PORTAL 
: 192.168.1.3 

COMMAND ied 
\a 
POST / DHCP SERVER GATEWA 


192.168.1.2 192.168.L.4 


ba ba 
fa be 
bd bo e 
W CUENTS 
192.168.1.11- 31 
Figure 36. Naval Postgraduate School TwiddleNet Network 


Testing Lab layout. 
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B. TESTING SCENARIOS 


To test the TwiddleNet System outside of the NPS 





TwiddleNet Network Lab, TwiddleNet was incorporated into the 
NPS Cooperative Operations and Applied Science & Technology 
Studies (COASTS) in the pursuit of specific scenario testing 
of all TwiddleNet iterations. Since 2005, COASTS has been a 
collaborative program with the Royal Thai Armed Forces, 


providing a venue to test promising technologies. The 





specific leveraging aspects of COASTS are: 


e To forge relationships between key organizations 
and individuals within the Royal Thai Armed Forces 
and US DoD. 











e To gain valuabl xperienc through technical 
demonstrations and field experimentation 
(particularly in Southeast Asia and Thailand). 








e To document processes for technology assessments, 


e To provide continued support by NPS Students and 
the ONR22 Program (38 Reserve Officer). 


The main purpose of COASTS was to experiment with 
candidate technologies in a field environment to: 





e Confirm technology maturity and CONOPS2?. 


e Assess candidate technologies and provide 


operational feedback to the science and technology 
community. 


e Provide a venue for NPS faculty research and 


Student thesis projects. 


22 ONR - Office of Naval Research. Coordinates, executes and 
promotes the science and technology programs of the United States Navy 
and Marine Corps. [15] 





23° CONOPS - Concept of Operations. Generally developed from a 
specific concept and is a description of how a set of system 
capabilities can be utilized to reach desired objectives or a specific 
conclusion for a certain scenario. 
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The COASTS Field Experiment (FEX) Series was designed 
to ensure technology readiness prior to insertion into 
specific scenarios and exercises. Organized FEXS were 


conducted at Camp Roberts, CA in preparation of integrated 





FEXs with the Royal Thai Armed Forces in Thailand. The 


following were the major field exercises and scenarios that 





integrated TwiddleNet for testing and assessment. 


1. Camp Roberts FEX III 2008 


This specific FEX presented a mock real-world 





environment that imitated the natural disaster of the 2004 


Boxing Day Tsunami24 incorporated PLrst Generation 





TwiddleNet, created by Clotfelter and Towle. The TwiddleNet 
system utilized the COASTS local network created by the 
Network Operating Center (NOC). TwiddleNet was utilized by 
the COASTS Mobile Emergency Command Post (MECP) and 
dispatched (on cue) to the affected site via scripted 
scenario. The TwiddleNet team was deployed via the MECP 


First Responder vehicle to the affected site where data was 








collected and disseminated among the team members and pushed 


to the JOCC. This scripted scenario (Appendix A) was a 








rehearsal in preparation for FEX IV as a joint exercise with 

















the Royal Thai Armed Forces. Overall, TwiddleNet 
functionality was a success. Pros, cons, and major results 
of this testing were presented in Chapter and synopsis of 





the after action report (AAR) is provided in Chapter VI. 








24 2004 Boxing Day Tsunami- The 2004 Indian Ocean earthquake was an 
undersea megathrust earthquake that occurred at 00:58:53 UTC on December 
26, 2004, with an epicenter off the west coast of Sumatra, Indonesia. 
The quake is known as the Sumatra-Andaman earthquake. This tsunami is 
all known as: 2004 Indian Ocean Tsunami, Asian Tsunami, Indonesian 
Tsunami, and Boxing Day Tsunami. [14] 
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2. Thailand FEX IV 2008 














After test results were garnered from FEX 2008, 





Ableiter and Rimikis made appropriate modifications for 
Second Generation TwiddleNet. The TwiddleNet team then 


traveled to Parachuap, Thailand, for a joint exercise with 





the Royal Thai Armed Forces on the Rayong Air Base. The 





same Boxing Day Tsunami scenario was performed, 
incorporating the TwiddleNet team as first responders for 


triage tasking and information dissemination. Pros, cons 

















and major system results were listed in Chapter and a 





synopsis of the AAR is provided in Chapter VI. 





3. Thailand FEX V 2008 


FEX V was again located at Parachuap, Thailand at the 


Rayong Air Base. Third Generation TwiddleNet, created by 





Ableiter, was incorporated into the same Boxing Day Tsunami 
scenario, deployed as first responders to the affected site, 
code named Humanitarian Assistance (HA) site. Royal Thai 
soldiers were utilized as, "Victims" to enhance 


functionality of the TwiddleNet system. 


The TwiddleNet team utilized the local COASTS WiFi 





network generated by the NOC. This WiFi network was 





expanded by a backhaul communication link, provided by 





Western Data Communications Technology, to the HA site. 
This allowed an expansion of the COASTS NOC WiFi network 


spanning several miles and across an ocean bay. 





Information, data, and photos were pushed from the HA site 





to the JOCC utilizing this communication link. 
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Power was generated from portable batteries, which 


supplied electricity for all TwiddleNet hardware components 





and the backhaul antenna. All TwiddleNet components, 





Backhaul Communications components, medical triage equipment 
and TwiddleNet medical triage personnel were transported to 


the HA site in the MECP transportation vehicle. 


Overall, the TwiddleNet system performance was a 














success. Pros, cons, and major results of this testing were 
presented in Chapter and a synopsis of the AAR is 
provided in Chapter VI. Several onsite photos are provided 





in Figures 37-41. 





Figure 37. Humanitarian Assistance site. 
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Figure 38. HA site w/Western 
Technology Backhaul Comm 


Data Communications 





unication Link. 





Figure 39. Royal Thai soldiers portraying injured 





survivors. 
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Figure 40. TwiddleNet onsite HA setup. 





Figure 41. TwiddleNet onsite Command Post. 
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4. Camp Roberts FEX III 2009 


The results collected from FEX V 2008 allowed Glidden 


to modify and stabilize Third Generation TwiddleNet, leading 




















to the most reliable iteration, Fourth Generation 
TwiddleNet. Although FEX 2009 did not incorporate a 
specific scenario, it allowed a venue in which to test 





TwiddleNet with other emerging technologies, i.e., the B-GAN 

















satellite for backhaul communication link to the JOCC. This 
B-GAN was also utilized to push/pull information and data 
between Camp Roberts and the NPS TwiddleNet Network Lab via 


the TwiddleNet Gateway computer. 


Overall, the TwiddleNet system performance was a 























success. Pros, cons and major results wer presented in 
Chapter and a synopsis of the AAR is provided in Chapter 
VI. 

5s Thailand FEX IV 2009 





FEX IV 2009 was located at Jomtien, Thailand, on the 





Satahip Naval Base. Although there was no specific scenario 
being executed, there were opportunities for continued 


testing in the same environment and several opportunities 











for TwiddleNet presentation and demonstration to the Royal 








Thai Armed Forces other VIPs. 


Overall, the TwiddleNet system performance was a 


success. A detailed assessment plan was provided in Chapter 

















and results are provided in Chapter VI. 
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VI. EXPERIMENTATION RESULTS 


A. TEST DATA 


For each COASTS FEX, a TwiddleNet Test Plan (Appendix 
B) was submitted to the COASTS NPS Team Lead to ensure all 


data was captured in a complete and organized fashion. 











Daily situation reports (SITREPS) were submitted each day 
during all COASTS FEXs. 


Raw testing data for the first three iterations of 


TwiddleNet was gathered and documented on TwiddleNet Test 








Data Sheets (Appendix C). 


B. AFTER ACTION REPORTS (AAR) 





AARS for all TwiddleNet testing that occurred during 
each COASTS FEX were submitted to the COASTS NPS Team Lead. 


ale Camp Roberts FEX III 2008 
a. Results 
Overall, testing was successful. All MOEs/MOPs 


were accomplished. 


Portal functions were reliable and all images 
captured by Clients were disseminated to all TwiddleNet Team 


Members and the JOCC. 





Note: Connectivity was intermittent by Handheld 
Clients, but all captured images and metadata were stored on 


creator’s handheld device. 
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b. AAR (Appendix D) 


2. Thailand FEX IV 2008 


a. Results 


Positive feedback was received for integration of 





Royal Thai Armed Forces in the TwiddleNet Humanitarian 





Assistance Boxing Day Scenario. 


All TwiddleNet components were successful in 


associating to the local COASTS WiFi network. 





Unfortunately, issues arose with heat and humidity 





affecting the TwiddleNet Handheld devices. All TwiddleNet 





Clients were successful in capturing, storing images and 





metadata for approximately 10 minutes befor th system 








froze. 


b. AAR (Appendix E) 


3. Thailand FEX V 2008 


a. Results 


Overall, testing and scenario execution was 


successful. Major achievements: 


(1) TwiddleNet Medical Triage Team were 
successful in gathering and disseminating patient data in 
real-time among team members, the TwiddleNet Command Post, 


and the JOCC. 
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(2) System functions for all TwiddleNet 
components occurred as expected, exhibiting system 


reliability. 


(3) All remote C2 centers received real-tim 





data, raising situational awareness of the Humanitarian 


Assistance site. 


(4) Backhaul antenna provided by Western Data 


Communications Technology was successful in linking 








TwiddleNet WiFi Network at the HA site to the COASTS WiFi 


network located several miles away. 


b. AAR (Appendix F) 


4. Camp Roberts FEX III 2009 


a. Results 





Due to severe time constraints for the TwiddleNet 





researchers, limited testing was conducted during this 


COASTS FEX. Major achievements included: 





(1) Successful testing of Fourth Generation 
TwiddleNet conducted. System stability and reliability 
confirmed. 

(2) Successful testing of TwiddleNet Gateway 
function. Information and data was shared between the 


TwiddleNet Gateway located at the NPS TwiddleNet Network Lab 





and the TwiddleNet Command Post located at Camp Roberts, CA. 
COASTS JOCC was also able to view data passed from the 
TwiddleNet Gateway. 
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5: Thailand FEX IV 2009 


a. Results 


As stated earlier, there was no COASTS’ FEX 





scenario executed. FEX IV 2009 provided a venue for 





TwiddleNet presentations and demonstrations to be given to 





Royal Thai Military Forces and other military VIPs. As a 





result, great interest was generated among the Royal Thai 


Military Forces, requesting market availability for the 





TwiddleNet Application. It also provided the opportunity 








for a comprehensive assessment to be conducted for Fourth 


Generation TwiddleNet. 


Additionally, successful testing was conducted for 


the following: 
(1) Multithreading of Clients. 


(2) Group Sharing function for individual 





TwiddleNet Teams. 


(3) Automatic re-association of Clients into the 


COASTS Local WiFi Network after travel outside of WiFi 





radius. 


(4) Automatic re-association of Clients when 


awaken from, “sleep mode.” 


Cc. PROS AND CONS OF FOURTH GENERATION TWIDDLENET 


As stated earlier, COASTS FEX IV 2009 provided a venue 





for the comprehensive assessment of Fourth Generation 





TwiddleNet. A narrative of the comprehensive assessment 
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plan was provided in Chapter within the Metrics Overview 





section. The complete Fourth Generation TwiddleNet 


Assessment Plan, to include testing results, is located in 


Appendix G. 
1. Pros 
a. Fourth Generation TwiddleNet exhibited an overall 





95% performance reliability resulting in the most consistent 





and dependable iteration. 





bs Consistent data dissemination during multi- 


threading option. 


C. Consistent data dissemination during group sharing 
function. 
il, Consistent reliability of Clients ability to re- 


associate into local WiFi network after, “sleep mode,” and 





when re-entering WiFi cloud radius. 





(1) All captured data was stored in Client files 


until re-association into WiFi network at which time data 





was sent to Portal for further dissemination. 





2. Cons 
a. There were no major technical issues; however, 
there were several minor observations. They are as follows: 


(1) TwiddleNet Clients have only an 80% ruggedization 


percentage. HP iPAQ Smartphones are several years old and 





need to be replaced with more a robust model. 
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(2) There was an intermittent 20% degradation with the 
operating distance. This was not completely understood and 


therefore, future testing should be conducted in this area. 
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VII. SUMMARY AND CONCLUSIONS 


A. APPLICATION TO THE DOD 


As mentioned earlier in this thesis, the main objective 





of TwiddleNet was to use a smartphone based networking 
application for first responder triaging during humanitarian 


assistance/disaster relief missions. However, future 





applications of TwiddleNet can be expanded to enhance other 








DoD missions. 


For example, current research for Fifth Generation 
TwiddleNet, conducted by LT Chey Hock Sim, Singapore Navy, 
and LT Hong-Aik Lee, Singapore Navy, proposes a new 
architecture to expand system capabilities to allow cross 


networking for information sharing [15]. This could 











potentially lead to an expansion of the triage area, 
allowing several first responder teams to deploy to several 
disaster areas with continuous capabilities for data 
collection and dissemination. This would undoubtedly lead 
to greater situational awareness for all C2 centers and 


major decision makers. 


TwiddleNet could also be integrated with other emerging 




















technologies, Ty Os. g Unmanned Aerial Vehicles to 
surreptitiously gather environmental data at a greater 
distance to gain an overall assessment of the target area. 


Further exploration into the realm of covert 
information gathering, TwiddleNet could be utilized to 


secretly capture and distribute photos and images of 


91 


specific targets/persons of interest during confidential 


missions, to distribute false images to mislead an adversary 








or for tactical deception. 


B. FUTURE WORK 


This work represents potential improvement in the 
overall TwiddleNet system. There is great opportunity to 


increase overall range, the number of deployed teams, 





network security, and the triage graphical user interface. 





These suggestions are strictly from a user perspective as my 





xpertis does not encompass programming skills. Some 


thoughts are listed below. 


1. Network Linking 


As mentioned earlier, Fifth Generation TwiddleNet is 
exploring the possibilities of expanding the range and 


number of deployed teams by linking two or more networks 





together. This would increase the deployable range and allow 





sharing between two or more networks, greatly enhancing an 

















overall situational awareness of the affected area(s). This 
research could possibly include utilizing satellite 
technology for more far-reaching capabilities, and to 


receive data and instruction from other medical facilities 





in networks around the world. 


2. System Security 


Currently, the only encryption available to TwiddleNet 
is WEP encryption, which leaves vulnerability gaps within 


the system. To enhance encryption, TwiddleNet could be 





incorporated with emerging technologies, such as GHOSTNet- a 
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secure and anonymous Virtual Private Network (VPN) service. 


Coupling Ethernet tunneling and proxy services to provide 





users safe and anonymous Internet access, GHOSTNet utilizes 





TSL (SSL) protocol with AES-256 encryption to secure the 





network along with PKI certificates and HMAC protection from 





replay attacks and UDP flooding [17]. 


3. Triage Graphical User Interface (GUI) 


Currently the GUI for the triage tasking is very basic 








and rudimentary. A more explicit graphical form with more 


drop-down menus could be generated. This would save time 





for the user/triage team member by eliminating the need to 








“type out” notes regarding injuries and current medical 


condition. 


For this improvement, a dedicated and experienced 





programming engineer would have to be employed. 


Cc. CONCLUSIONS 


This work successfully tested and evaluated all 


iterations of the TwiddleNet Networking application. We 





conclude that this system is extremely worthwhile and 


beneficial, with a strong foothold in the realm of adhoc 





networks for first responder medical triaging. TwiddleNet 





has been extremely successful in the field for gathering and 


disseminating information, images, and data in real time. 





This is an unmistakable advantage in gaining situation 
awareness for all command and control centers and for all 


decision makers. 


oS 


With continuous incremental improvements 


and stability, Fourth Generation 


become an extremely powerful 





unlimited possibilities of futur 


and 


Twi 


Va 





ddleNet has 


luable system, 





development 


integration, and commercial network optimization. 


hope that a dedicated 





(and funded) 


R&l 





D program will 





in reliability 


quickly 


Sy, 








with 


Do 





D 





is my 


bring 








TwiddleNet into marketable productization in the very near 


future. 
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APPENDIX A. EXCERPT COASTS TSUNAMI SCENARIO SCRIPT 


COASTS FEX [TY TwiddleNet Scenario Script 
Backpround 


An unexpected tropical storm racing across the Gulf of Thailand 
has led to a category 4 Typhoon causing flash flooding in the small 
coastal town of Rayong, Thailand. Sixty minutes followime the 
conclusion of the typhoon, the COASTS MECP 1s deployed to 
assess damages and set up triage area. Additionally, a Military 
Operation in Urban Terrain (MOUT) within the main city of 
Rayong, Thailand (to seize and secure key combatant targets) has 
been delayed due to the typhoon. MUOT to take place 
approximately sixty minutes following the completion of the 
typhoon, in order to maintain the element of surprise. 


Humanitarian Assistance Phase-| fin black font) 





00:00 Phase 1 COMEX. Sixty minutes after the conclusion of 
the tropical typhoon, MECP 1s deployed to disaster area in order to 
assess damages and set up triage area. Concurrently, Military 
Operations in Urban Terrain (MOUT) and clearance and capture of 
enemy personnel from Urban Built-Up Areas (UBLUA) by the 
COASTS Combined Task Force (CTF) has commenced. Thirty 
minutes after the completion of the MOUT, the MECP ts deployed 
to set up triage area. The CTF-COASTS liaison to COASTS team 
requests assistance to survey the scope of the injuries / casualties, 
search and rescue for injured survivors and initiate initial medical 
triage efforts for two locations. After an additional hour of 
coordination and crisis planning, COASTS has determined how 
best to support this request and coordinate the support with the 
host-nation. Time elapsed since MOUT completed +02:00. 


00:01 JOCC Directs AU-23 Mosquites to be launched from 
Wing-AX and dispatched to disaster region and MOUT area. 


oS 


0:01 


0:01+30 


0:02+30 


0:03 


00:02 


JOCC Director (Ch-]}: “Airboss, JOCC, launch alert AU-23 to FLOOD 
region.” 
Airboss (Ch-1): “Roger, launch alert AU-23" 


Airboss (VHF): “Mosquito 01, Atrtoss, launch and depart to FLOOD area, 
report on ground routes and extent of damage” 
Mosquito 01 (VHF): “Roger, launch and depart" 


Airboss (VHF): “Mosquito 02, Atrooss, launch and depart to MOUT area, 
report on pround rowtes and extent of damage" 
Mosquito 02 (VHF): “Roger, launch and depart" 


Mosquito 01 (VHF-tower): “Rayong Tower, Mosquite 0] ready for takeotT, 
tumout to northwest and departure to south.” 
Tower (VHF): Provides necessary clearance. 


Mosquito 02 (VHF-tower): “Rayong Tower, Mosquita 02 ready for takeotT, 


tumout to northwest and departure to south.” 
Tower (VHF): Provides necessary clearance. 


JOCC Directs two Mobile Emergency Command Post 


(MECP) Teams to depart Jomt Operation Command Center 
(JOCC) for MOUT zone. 


0:02 


0:03 


4 


00:20 


JOCC Director (Ch-1}: “"MECP-A, JOCC, depart for flood zone” 
MECP-A (Ch-1}: “Roger, departing” 


JOCC Direetor (Ch-1}: “MECP-B, OCC, depart for MOUT zone" 
MECP-B (Ch-1): “Roger, departing” 


JOCC Director (VOIP): “PCF, JOC, transit to offshore of flood zone" 
PCF (VOIP): “Roger, departing” 


AU-23 arrives over FLOOD area, video provided to 


COASTS JOCC and to remote sites via COASTS network. PCF 
arrives in MOUT area. 


00:20 


Mosquito 01 (VHFe “JOCC, Mosquito O1, ] am over FLOOD zone now. 
Kany resort buildings have sustained significant damage. Large number of 
bodies in and around beach landscape. Will transmit video.” 

JOCC Director (VHFI: “Mosquita 01, JOCC, understand significant 
damage, loss of Lift and injured POWs / noncombatants, waiting on video" 
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O25 Mosaquita 02 (VHF): “IOCC, Mosquite 02, [ am over MOLT area now. 
Fighting in Fortified Objectives (FORO) has sustained significant damage. 
Large number of bodies in and around urban landscape. Will transmit 
video.” 
JOCC Director (VHF): “Mosguite 02, JOCC, understand significant 
damage, loss of life and injured POWs / noncombatants, waiting on video" 


M:20+30 PCF (VOIP: “JOCC, PCF, I am offshore from FLOOD zone. I confirm 
report, significant damage and bodies awash in water.” 
JOCC Director (VOIP): “PCF, JOCC, thank you for confirmation" 


00:20 Timeline compression. 60 minutes simulated elapsed. 
After short survey of disaster areas, routes are determined into the 
area for disaster relief teams and military extraction teams. JOCC 
relays this information to the inbound MECP Teams. Both ALUJ-23s 
use loiter capability to remain over both areas and provide 
continued SA and support. Both MECP teams arrive in disaster 
areas within seconds of each other. 


0:20 MECP (SATCOM® “TOOC, MECP-A, we have arrived in FLOOD zone, 
initiating setup, will launch UAW, standby for video, TwiddleNet, and 


reporting” 
JOCC Director (SATCOM): “Roger MECP-A, JCC standing by” 


M22 MECP (SATCOM?): “J00C, MECP-B, we have arrived in MOUT area, 
initiating setup, will launch UA, standby for video, TwiddleNet, and 
reporting” 

JOCC Director (SATCOM™: “Roger MECP-8, JOCC standing by 


00:50 MECP teams set up complete (including TwiddleNet) 
and initial reports data-linked back via satellite / B-GAN to 
COASTS JOCC. Mini-UAYV supports MECP, reporting on 
damage and possible survivors to surrounding area through aerial 
surveillance. 


0:50 MECP-A (SATOOM): “JOCC, MECP-A, you should be receiving video, 
UAV video, and TwiddleNet. FLOOD region has suffered significant 
damage to all buildings; many survivors have sustained extensive injuries. 
This is a major disaster zone. Inland soad structure is intact, but refugees are 
flooding the network. Local communications are down. Medical assistance 
and howsing needs have priority.” 
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JOCC Director (SATCOM}: “MECP-A, JOCC, Roger, will pass your 
information to higher, continwe observation and reporting” 


(54 MECP-BISATCOM): “JOCC, MECP-B, you should be receiving video, 
UAY video, and TwiddleNet. MOUT area has suffered significant damage to 
several buildings; enemy POWs and noncombatant survivors have sustained 
extensive injuries. This is a major disaster some. Inland road structure is 
intact, but refugees are flooding the metwork. Local communications are 
down. Medical assistance and housing meeds have priority.” 

JOCC Director (SATCOM): “MECP-B, JOCC, Roger, will pass your 
information to higher, continwe observation and reporting” 


00:56 Reports on damage/scope of disaster relayed from 
COASTS JOCC to host-nation Command Center and local NGO 
headquarters in capital. 


0:58 JOCC Director (Phone): Makes contact with host-nation command center{s) 
and local NGO headquarters to confinm receipt of information 


00:60 Phase 1 FINEX: Mini-UAV recovers. MECP teams return 
to base. 
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APPENDIX B. EXAMPLE TWIDDLENET TEST PLAN 


From: Lillian A. Abuan, LCDR, $C, USS. 
Dirk Ableiter, LT, GNY 
COASTS 


To: Jim Ebleri 
COASTS. 


Subj: FTX - 11 TWIDDLE NET EVALUATION TEST PLAN 


1. Overall and daily objectives: 

a. Scenario: Deploy a Mobile Emergesxy Command Pos (MECP), utlimme small, loght 
metpht handhelds that supports heckheul commsnications from a diester zone to DOLLA 
telemedicine center. 

bh. Utilize TwiddleMet for function related medical triage tasking during mass casualty / 
humanitarian ops. 

c. Utilize TwiddleNet to test and evaluate the effectiveness of all equipment associated for 
captaning and disbursing triage images; smooch mformation flow. 

do Utilize TwiddleMet bo create an infrastructure that denotes 2 hierarchy for scenario 
evalaation, info pethering, and distvbution in order to analyze optimal solution; 
completely evaluate sitaation throvagh captures images for highest optimal solutions. 

e. Create a step by step decision process to best equip first responders when preparing to 
dispatch aid. 

2. Time blocks expected for testing. Worihin those time blocks: 
a. Persongel required: 
1) Dirk Adbeiter, Lilian Abuan 
2) 3 person teem to use pempheral TwiddleNet equipment to test functoonalsty dering a 
mass cesualey / bumandiarian triage scenara. 

bh. Equipment required 

th) TwiddleNet Portal ink Cote) (small computer] 
2) § Handheld devices renning TwoddleNet 
3) Ome laptop runsing the Command Post (Dick's computer) 
4) Everything sing the given network 
c. “Hard” and “Soft" cmelines 
i) Wednesday: Sering up of TwiddleNet 1000 — 1700 
e. Drill down for TwiddleNet set up and equipment use 
2) Thursday: 
a. Setting up Mobile Command Post 
bh. idenofying Commend and Coctrol Hierarchy 
co. Condect testing from O00 ~ 1700 
@ SET i: Randomly take pictores with five devices 
simultaneously in automatic mode (take pig. rest I) 
Test “mulithreading™ (30 mm, Team: 3) 
@ SET 2: Same as one but enter different tags with 
keyboard (30 min, Team: 3) 
@ SET3: TED. Limited device testing. 
3. Measuzes of Effectiveness / Measumes of Performance for equapment yira're texting 
&. Team ability to take photos acd disburse to PORTAL and MECF 
b. Data sharing capabilities: speed, size of dein 
4. Independend, dependesit, and comirolled variables (respectively: What you're changing each time, 
wha you're mezsuring, and what stays the same for each ran) 
4. Data required froen other CORASTS members (ie. APRS GPS location, METOC info) 
2. Network info 
6. Topology diagram ! sketch ! description of where you are setting up equipment, of applicable 
a. TED. The Triage Team wall disburse within WiFi radias. 
7. Matix for data collection — what parameters yoo intend to capture es independent variable 
changes. 
®. Data gathering lamas: battery life of handhelds, area of operation, weather conditions, 
equipment effictency 
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APPENDIX C. TWIDDLENET TEST DATA SHEET 
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Devices / Data Post Server 














101 





TH 


IS PAGE 








NTENTIONALLY LEFT BLANK 








APPENDIX D. TWIDDLENET COASTS FEX III 2008 AAR 


18 February 208 


From: Lillian A. Abuan, LCDR, 2, 45) 
Dirk Ableiter, LT, GN 
COASTS. 


Ta: Jim Edler 
COASTS 


Subj: FEX U1 TWIDDLE NET HUMANITARLAN ASSISTANCE SCENARIG TEST 
AND EVALUATION RESULTS 


1.) Overall objeciives: 

a. Soenerio: Deploy a Mobale Emergescy Command Post (MECP), uolieme small, leght 
weight hendhelds chat supports backhaul commesnications from a disaster zone bo the 
Tet CP for orientation aod desiribuon to the UCLA telemedicine cecier. 

Bb. Utilize TwiddleMet for function related medical triage tasking during mass casualty / 
umandiarian ops. 

c. Utilize TwiddleMet to test and evaluate the effectiveness of all equapment associated for 
captaring and disbursing triage images; smooch mformanion flow. 

@ Utilize TwiddleMet to create an infrastructure that denotes 2 hierarchy for scenario 
evaluation, info gathering, and distdbution in order to anelyze optimal solution; 
completely evaluate sibaation ihroagh capes images for highest optimal solutions. 

e. Create 2 step by step dectsion process to best equip first responders when preparing to 
dispatch aid. 

2. TwiddleNet Equipment tested 

a. TwiddleNet Portal Link O00 (mobile computer located in the MECP 
vehicle) 

hb 4 Handheld devices running TwiddleNet 

c. TwiddleNet Laptop located at the TOC 

cd Available WiFi network 

3, Measures of Effectiveness ! Measures of Performance 

a. TOC CP (laptop): SUCCESSFUL 
-- Tecelved images and data 
--Note: “REFRESH” button needed to be pressed for receipt 

b. MECP(OGOr SUCCESSFUL 
— Tecelved images and data 

a} NOTE: currently receiving same images / data as TOC 
b} FUTURE: need more independence: HIERARCHY 
(1) Handhelds (2) MECPIOQO (3) TOC (4) TELEMED UCLA 
-- PORTAL function SUCCESSFUL 
c. INTERNAL SYSTEM APPLICATION: SUCCESSFUL 
— Handhelds able to take photos. 
a) NOTE: delay between photos longer than expected 
-- Multithreading: SUCCESSFUL 
a) Handhelds able to take photos simultancously and send to 
Portal for distribution 
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d CONNECTIVITY: INTERMITTENT 
a) No indication of non-comnectivity by handhelds 
~-images stored on handhelds until connectivity reestablished 
-NOTE: Dirk creating and implementing new program for 
real-time indication of connectivity; debugging 
system 
b} Intermittent connectivity occuring when MECP vehicle in low 
areas surrounded by hills 
4. Future Testing 
a. Implementing “ready-made” triage forms for on-site medical evaluation 
bh MECP s TCC Hierarchy established; independent receipt of information 
c. GHOSTNet for Handhelds 
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APPENDIX E. TWIDDLENET COASTS FEX IV 2008 AAR 


26 March 2008. 


From: Lillian #&. Abuan 
LCDR §5C USN 
COASTS 


To: Jim Ehlert 
Program Manager 
COASTS 


Via: Juan Gutierrez 
LCDR UE 
COASTS 


Bub}: COASTS FEX IV 2008 THAILAND HUMAWITARIAN 
ASSISTANCE ANDO TEST/EVALUATION OF TWIDDLEWET AFTER ACTION 
REPORT ({S4R] 


1. Major Achievements 


M@ Bumanitarian Scenario 
2) Positive feedback for integration of Thai 
QOUnLeEperts for participation in disaster 
driil 
bh) Positive feedback for integration of 
Corpsmen reservists 
2) Positive feedback for location of HA site 


M@ TwiddleNet system 

2) Positive test for associating to moblle 
access points, 1.e., JOCC AF, HU AP 

b) TwiddleNet JoCC Command Post Server 
Positive test for essociating and 
recognition of TwiddleNet Fortal 

¢) TwiddleNet Handheld devices § clients 
Positive test for image & data gathering 
and sharing w/ other dewices / clients via 
TwiddleNet Portal 

dj TwiddleNet Handheld devices / clients 
Positive test for storage of all image é 
data 


#. Major Froblems 


M@ TwiddleNet Handheld dewices /§ clients severely 
affected by heat and humidity 
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5) 
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qd) 


2 
f 


g 


} 
} 


— 


All devices able to capture, store, share 
images for appx. 10 mins before freezing 
Constant resetting of device required 
Overheating occurring consistently within 
minutes of introduction into environment. 
Cooling no longer alleviated issue 
Frogram unable to run on handhelds 

Error messages occurring within § minutes 
of running program 

Issue still unresolved. Suspect program 
will have to be reloaded 


TwiddleNet system unable to be tested early due 
to lack of Network 


Foor comms during scenario 
2) Very difficult to hear / understand Jocc 


team leader 


b) No comms with FC for extraction portion of 


scenario 


4. Lessons Learned 


Problem: 
2) HP iPAQS are not robust enough to handle 


environment 


Db) Hand held radios not strong enough far 


distance from the JoOcc 


Description: 
a} Cooling system not enough for heat «& 


humidity 


Lessons learned: 
2) Antennas on handhelds mot strong enough to 


break through RF interference causing unit 
to constantly work harder / hotter 


b) Processor cooling system not strong enough 


for environment 


Solution: 
2) Acquire better handheld clients 
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APPENDIX F. TWIDDLENET COASTS FEX V 2008 AAR 


Dr. Singh / LCDR Abuan 
AAR 


Major Achievements: 


1) 


2) 


3) 


TawiddleNet enabled the Medial Triage Team to share patient data and medical 
Mage information in real-time among the team members, as well as, with the 
Mobile Emergency Command Post at the Humanitarian Assistant site and the 
Joint Operations Command Center. 


a) AN iPAQ handheld devices able to take and receive photos: Multithreading 
Successful. 

b} All handivelds able to reecive audio alerts from other handhelds 

c) Portal (000) able to visually display each specific handheld upon association 
i disassociation to Portal. 

d} Portal (O00) dismayed written alert upon receipt / distibution of cach image 
taken by all handhelds. 


Remote command centers were able to get complete situational awareness of the 
Humanitarian Assistant site in eeal-time with pictures and annotated text. 


a) Photos tagged with personal PT info 
b} Photos tagmed with medical triage information 


Network clowd established to cover 308) yd. radius at Humanitarian Assistance site 
using Wester Data Communications technology: SUCCESSFUL 


a) TwiddleNet associated w! Western Data Communications Case: SUCCESSFUI 


b} Redline 802.16 backhaul established for commection of Humanitarian 
Assistance site and JOCC: SUCCESSFUL 


Major Problems (indicate if unresolved) 


3 


NTR 


Lessons learmed: 


1) 


2) 


Problem: Association of phones with open WiFi networks 

Description: TwiddleNet continually attempting to associate with multiple open 
WiFi networks and dropping the designated WiFi network (HU_AP} 

Solution: Stabilize software application to maintain commection with dedicated 
WiFi nctwork (HU_AP) 


Problem: Unstable cameras 

Description: Cameras on iPAQ hardware slow, unable to take multiple photos in 
quick succession, would continually freeze during use of application. 

Solution: Acquire stronger and faster hardware, which is now available 
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3} 


4) 


6) 


Problem: Requires phone pre-configuration for static IP addresses. 
Description: Unable to automatically associate TwiddleWect hardware to 
dedicated WiFi network. Must continually input static IP addresses tn order for 
associating HA UP Comme Case to TwiddleNet hardware. 

Solution: Allow comms case or dedicated WiFi network an allotted range of IF 
addresacs and assign te TwiddleNet hardware via DHCP. 


Problem: So specified Thai translator 

Description: There was no specified translator to communicate with Thai 
counterparts volunteering as Tsunami Survivors 

Solution: Identify translater prior to 1" dry run of scenario. Maintain the samc 
VOIUDLECES 85 UNE Survivors to Maintain continuity of experience and 
knowledge. 


Problem: Mo covered arca for rain 

Description: So avatlable tent for protection from weather elements. Unable to 
procure “pop-uwp" tent from nearby town 

Solution: Procure “pop-up” tent from Bangkok 


Problem: No lighting available for Humanitarian Assistance site 
Description: For night-time scenario, Humanitarian Assistance site MUST have 
light for the following reasons: 
a} SAFETY 
bi CLEAR IMAGE CAPTURE 
c} SET UP OF EQUIPMENT 
Solution: Acquire generator(s} amd flood lights 


Problem: Had radio comms / No comms plan weed 

Description: Radios used were not strong enough for clear comms from 
Humanitarian Site to JOCC. The comms plan that was available was not used. 
Solution: Acquire stronger radios. Populate and use the comms plan. 
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APPENDIX G. TWIDDLENET FOURTH GENERATION ASSESSMENT 
REPORT 


TWIDDLESET ASSESSMENT REPORT 
DESCRIPTION: 

» TwiddleNet is an NPS sponsored project to develop a smarphone-based system 
to facilitate instantancous capture of data in support of medical triage / urban 
assault, warfighter patrol / HAZMAT response that can be tagged and 
disseminated using any mobile WiFi network. 


a 


Unlizing Commercial-off-ihe-Shelf components, TN team members maintain 
complete autonomy of all captured data, which is shared among specified team 
members, stored for redundancy by the Command Post server and later 
discriminately shared. 


¥ 


100% gain of enhanced situational awareness for mobile monitoring during all 


types of scalable operations. 





Ces, ST La 


soe i 





OBJECTIVES FOR CVO9 
& TwiddleNet performance data will be collected and analyzed during Crimson 
Viper 2009. 
» The overall assessment strategy for CV09 TwiddleNet is to evaluate 
Effectiveness, Suitability, and Mission Impact of the various components under 
physically demanding conditions & with different network configurations. 


» Document environmental data, network radius & uncontrollable variables 
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»* Document environmental data, network radius & uncontrollable variables 
® Measures and data sources will address, COs, Objectives, MOEs and MOSs as 
well as a data collection and analysis approach 


»* Expenment Overview: 


a 


a 


a 


o 
RESULTS 
» Analysis Result | - 6: Successfully completed all objectives. Analysis of results 
contained in conclusions. 


All components assembled and end-to-end transmissions confirmed by TN 
Cmd Post 

Avocess to images/data on Cred Post server tests from remote locations 
Handhelds tested at different distances for reliability / speed of data 
transfer 

System continuity documentation, troubleshooting, and course comection 
System test of “Group Feature” and simultancous data multithrcading 
WiFi cloud area tested with Fhy Away Kit 


Viewure Soarce Product 


ROOKE. Lele: Portormance reizability of Twiddlese system TOANCA 


MOORE 1-1-2: Percent of daw reocived 


sero fa] 


= a. 
MOE 1-13: Percent of daa captured and shared [Ten ocA [958 | 
BR a 


eli: Percent of sottwane reliabality a5 





MOE 1-1-5: Percem of hardware reliatill [renoca [a 


NELEE 








MEOE | -2 





e4e]: Miaximum outer distance o incite: id “TALES A 


Mearure Source 


peeing. | 
Devices and Twiddie Set Syanem 





PUM: | =J-2: Maximum indoce operating distance of Handheld 
Devices and TwiddleMet System TCANOCA (lew 
: sirertenence| 
MOE [J.i: Maximum oundoce senaing range of Handheld a) oe 
Devices to OCR) TCANICA 
tnieclrace) 
NOUME | Sak: Miaximum indoor seman: range of Handheld LOD wes 
Devices bo O10 TCANOCA (Low 
stherlencted) 












F Source Prodect 
“1h Teiddlese ever regeedieation TOAOCA | Be | 


NOCHE. 1-2-2) Percent of seca dane received / shared i the TACHA 


TOAOCA 
TOAOCA | Le | 
| TAOCA | 
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POE ET Avera Baer 1: avenge sey if a ee 
SHOE 5-3: Naber and pe of bananas | “texoca | sx —] 


“2-2: Is the vysiem eaay 9 maintain? 
: AUPE Pe Peqquinemones reasoneeieT 










Mrasere Source Prodect 
PHONE 2-3-1) I cack OL! cay to comprehend and monitor! 
Ob 2-2; Chere dhe Tedkdicsel svete cndance eecr etustional TCAIGCA 


wwarencss? 
OE 2-3-: How nach training ime w rogaarod for the user rane | ithe | 
,TONOCA | YES | 


REOWE 2-3-1) |e if aay LO eerrect eon 2 oeeration? 
or) 












WELKE 2-3-5 Is adequate documentninn avedable fi Seer 
ivitem up, and nreubledeet proiies 


CONCLUSIONS 


= 93%) Coverall succes rate 


95%) Performance Reliability duc to minor issues with data sharing 





¥ ¥ 


80% Rugeedization — subjective score based on my assessment 
»* 20% Degradation with operating distance — Not completely understand, More 
research wy Dr. Singh 
RECOMMENDATIONS 
» Major Technical Issucs 
o Nothing to Report 
» Minor Technical [ssues 
o WiFi Cloud reliability 
o WiFi must be tumed off on handhelds when in sleep mode 
* To accommodate conservation of battery 
o System reliability during periods of idleness 
*® Handhelds must be weed at least once every our to maintain 
commechvity to system 
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® Path Ahead 
ao Purchase new Smartphone with more AM, longer battery life, better 
camera 
= Increase robustness 
o Enlarge WiFi cloud 
= Purchase outdoor access points to create WAN 
ao Explore possibility of use with other technologies, Le. UAVs 


DISTRO 
Linclassi fied. 
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